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Abstract 


This  report  develops  a  queueing-theoretic  solution  to  predict,  for  a  real-time  system,  the  aver¬ 
age-case  latency  of  aperiodic  tasks  managed  by  a  sporadic  server.  The  report  applies  this  the¬ 
ory  to  a  model  problem  drawn  in  the  domain  of  industrial  robot  control.  In  this  model  prob¬ 
lem,  a  controller  with  hard  periodic  deadlines  is  “open”  to  third-party  plug-in  extensions.  The 
sporadic  server  is  used  to  limit  the  invasiveness  of  aperiodic  tasks  on  the  controller’s  hard 
deadlines.  The  theory  developed  in  this  report  is  used  to  predict  the  average-case  latency  of  a 
plug-in  managed  by  a  sporadic  server. 
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1  Introduction 


The  goal  of  the  Predictable  Assembly  from  Certifiable  Components  (PACC)  Initiative  at  the 
Carnegie  Mellon®  Software  Engineering  Institute  (SEI)  is  to  enable  the  construction  of  soft¬ 
ware  systems  from  components  in  a  manner  that  allows  for  automatic  prediction  of  system 
behavior  [Wallnau  03].  This  goal  is  realized  by  developing  and  enhancing  component  tech¬ 
nologies,  using  and  extending  property  theories,  and  developing  prototype  tools  and  methods. 
This  report  focuses  on  extending  property  theories  for  performance — one  of  the  quality  at¬ 
tributes  for  which  the  PACC  Initiative  is  developing  a  prediction  capability. 

Performance,  or  specifically  timing  behavior,  is  important  to  all  systems.  For  some  systems, 
ensuring  the  satisfaction  of  hard  deadlines  is  of  primary  importance.  For  other  systems,  miss¬ 
ing  deadlines  occasionally  is  acceptable,  provided  the  miss  rate  is  guaranteed  to  not  exceed  a 
specified  threshold.  Finally,  for  some  systems,  satisfactory  performance  is  defined  as  meeting 
average  latency  requirements.  Our  ultimate  goal  is  to  have  prediction  capability  for  all  these 
types  of  systems. 


The  initial  work  in  creating  a  performance  property  theory  (called  A,aba)  for  a  prediction- 
enabled  component  technology  (PECT)  was  documented  by  Hissam  and  colleagues  [Hissam 
02].  X,  is  short  for  latency,  and  ABA  is  short  for  Average-case,  with  Blocking  and  allowing  for 
Asynchrony. 

XAba  is  built  on  a  body  of  work  known  as  Generalized  Rate  Monotonic  Analysis  (GRMA) 
[Klein  93],  which  offers  the  ability  to  predict  worst-case  latency  to  ensure  that  hard  deadlines 
are  met.  XABa  extends  GRMA  to  predict  average-case  latency.  XABA  is  constrained  to  a  set  of 
component  assemblies  whose  interpretation1  reduces  to  sequences  of  tasks  (unit  of  concur¬ 
rency)  initiated  periodically  using  both  synchronous  (e.g.,  call/retum)  and  asynchronous  (e.g., 
message-passing)  communication. 


The  focus  of  this  report  is  to  generalize  the  XABA  theory  to  include  tasks  that  are  initiated  sto¬ 
chastically  (or  aperiodically — the  terms  are  used  synonymously)  in  addition  to  periodically. 
This  work  entails  developing  a  new  analytic  theory  for  predicting  the  average  latency  of  ape- 


®  Carnegie  Mellon  is  registered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie  Mellon  Uni¬ 
versity. 

1  Interpretation  assigns  to  an  assembly  specification  a  meaning— or  semantics — in  some  property 

theory.  Interpretation  is  described  in  detail  by  Wallnau  [Wallnau  03]. 
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riodic  events  in  the  context  of  a  collection  of  real-time  periodic  events.  This  generalization 
was  motivated  by  systems  that  must  handle  aperiodic  events  without  sacrificing  the  hard  real¬ 
time  deadlines  of  periodic  processes  or  tasks.2  This  new  theory  also  imposes  analytic  con¬ 
straints — in  particular,  systems  must  manage  aperiodic  events  with  sporadic  servers. 


The  sporadic  server  scheduling  algorithm  (SSSA)  [Sprunt  89]  was  invented  to  solve  the  prob¬ 
lem  of  protecting  periodic  events  with  hard  deadlines  from  bursts  of  high-priority  stochastic 
events  while  giving  high  priority  to  processing  stochastic  events.  The  hallmark  of  a  sporadic 
server  is  that  it  provides  a  periodic  “virtual  processor”  within  which  aperiodic  events  can  be 
processed  and  analyzed.  This  report  provides  a  queueing-theoretic  foundation  for  analyzing 
the  average-case  latency  of  aperiodic  events  handled  by  a  sporadic  server. 

Section  2  provides  thumbnail  sketches  of  GRMA  and  queueing  theory,  which  serve  as  build¬ 
ing  blocks  for  this  work.  In  Section  3,  we  describe  sporadic  servers  in  more  detail.  In  Section 
4,  we  develop  a  new  property  theory  for  predicting  the  average-case  latency  of  aperiodic 
events  serviced  under  the  control  of  a  sporadic  server.  In  Section  5,  we  describe  a  model 
problem  from  the  domain  of  robotics  and  show  how  to  apply  the  property  theory  to  that  prob¬ 
lem.  We  conclude  in  Section  6  with  a  brief  description  of  where  this  work  is  headed. 


2  The  terms  task  and  process  are  equivalent  for  the  purpose  of  this  report. 


2 
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2  Performance  Approaches 


As  described  by  Wallnau  [Wallnau  03],  a  PECT  comprises  a  construction  framework  and  one 
or  more  reasoning  frameworks.  Basically,  a  construction  framework  provides  a  vehicle  for 
specifying  a  set  of  assemblies  that  are  automatically  analyzable.  For  an  assembly  to  be  ana¬ 
lyzed,  it  is  interpreted  and  its  interpretation  is  evaluated.  Interpretation  is  the  process  of  trans¬ 
lating  an  assembly  into  a  property-theory-specific  representation  suitable  for  evaluation  via 
logical  rules  of  inference  and/or  simulation. 

In  the  following  subsections,  we  describe  the  notation  and  assumptions  of  the  property  theo¬ 
ries  we  are  using  and  developing. 


2.1  Basic  Notation 

We  assume  a  single  processor  executing  a  set  of  periodic  tasks  and  a  single  aperiodic  task. 
Each  task  is  stimulated  to  execute  by  the  arrival  of  a  sequence  of  events  (either  generated  ex¬ 
ternally  such  as  by  the  arrival  of  a  message  or  internally  such  as  by  a  clock  interrupt).  When 
the  events  for  a  specific  task  arrive  at  regular  intervals,  that  task  is  designated  as  periodic 
with  a  period  of  Tj  (or  Tp  when  there  is  only  one  periodic  task).  When  the  arrivals  are  not  pe¬ 
riodic,  they  are  aperiodic  (or  sometimes  we  say  stochastic  or  random).  In  this  case,  the  aver¬ 
age  interarrival  interval  is  denoted  by  Ta. 

Each  task  (regardless  of  whether  it’s  periodic  or  aperiodic)  executes  for  a  constant  amount  of 
time  when  stimulated.  This  time  is  denoted  by  Si,  (or  Sp)  for  the  periodic  task  and  Sa  for  the 
aperiodic  task.  We  refer  to  this  time  as  the  execution  time  or  service  time. 

Over  a  long  period  of  time,  each  task  uses  a  portion  of  the  processor.  For  periodic  tasks,  this 
usage  is  usually  referred  to  as  utilization  and  denoted  by  Ui  (or  Up),  where  Uj  =  S/Tj.  For  ape¬ 
riodic  tasks,  this  usage  is  referred  to  as  the  task’s  traffic  intensity  and  denoted  by  p  where 
p=S/Ta.  (While  traffic  intensity  usually  refers  to  all  tasks,  p=S/Ta  is  referring  to  the  traffic 
intensity  of  a  single  task.) 

Later,  we  describe  a  special  mechanism  for  scheduling  the  execution  of  aperiodic  tasks — the 
sporadic  server.  The  sporadic  server  is  characterized  by  two  parameters:  an  execution  budget 
and  a  replenishment  period.  The  execution  budget  is  denoted  by  Sss,  and  the  replenishment 
period  is  denoted  by  Tss. 
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Each  task  also  has  a  latency  associated  with  it.  The  latency  (or  waiting  time)  is  how  long  it 
takes  to  complete  the  servicing  of  an  event  in  the  face  of  preemption  from  higher  priority 
events  and  the  queueing  time  due  to  prior  events.  For  periodic  tasks,  we  might  be  concerned 
with  either  worst-case  or  average-case  latency.  For  aperiodic  tasks,  we  are  concerned  with 
average  latency.  In  this  report,  we  denote  latency  with  the  random  variable  W  and  average 
latency  as  E[W]. 


The  next  two  subsections  offer  thumbnail  sketches  of  GRMA  and  queueing  theory. 


2.2  Generalized  Rate  Monotonic  Analysis  (GRMA) 

GRMA  is  a  theory  for  predicting  the  worst-case  latency  of  a  collection  of  hard  real-time 
tasks.  Rate  monotonic  analysis  (RMA)  grew  out  of  the  fixed-priority  scheduling  theory  of 
periodic  tasks.  The  term  rate  monotonic  originated  as  a  name  for  the  optimal  task  priority 
assignment  in  which  higher  priorities  are  accorded  to  tasks  that  execute  at  higher  rates  (that 
is,  as  a  monotonic  function  of  rate).  Rate  monotonic  scheduling  is  a  term  used  in  reference  to 
fixed-priority  task  scheduling  that  uses  a  rate  monotonic  prioritization.  The  original  theory 
was  subsequently  generalized  to  the  point  of  being  practicable  for  a  large  range  of  realistic 
situations  encountered  in  the  design  and  analysis  of  real-time  systems  and  is  now  referred  to 
as  GRMA,  a  codification  of  which  is  discussed  by  Klein  and  colleagues  [Klein  93].  Basic 
GRMA  problems3  have  the  following  characteristics: 

•  They  involve  a  collection  of  periodic  tasks  executing  on  a  single  central  processing  unit 
(CPU).  In  the  simplest  case,  each  task  has  a  period,  a  priority,  and  an  execution  time. 

•  They  use  priority-based  preemptive  scheduling. 

•  Tasks  may  synchronize  to  use  a  shared  resource. 

•  Deadlines  are  assumed  to  be  at  the  end  of  the  task’s  period. 

•  In  some  cases,  tasks  may  be  broken  down  into  a  sequence  of  subtasks.  The  entire  se¬ 
quence  is  initiated  periodically;  however,  each  subtask  has  its  own  execution  time  and 
priority. 

3  These  problems  are  basic  in  the  sense  that  GRMA  can  handle  a  wider  class  of  problem  than  is 
characterized  here. 
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Several  Key  GRMA  Results.  One  of  the  principal  goals  of  GRMA  is  to  calculate  worst-case 
latency,  which  can  then  be  compared  with  a  deadline  to  determine  whether  it  can  be  met. 
Computing  worst-case  latency  requires  knowing  that  zero-phasing4  produces  the  worst-case 
latency.  The  worst-case  latency  for  a  task  occurs  when  all  the  high-priority  tasks  become 
ready  to  execute  at  the  same  instant  as  the  given  task.  This  moment  is  known  as  the  critical 
instant.  The  following  recursive  formula,  Equation  (1),  can  be  used  to  compute  the  worst- 
case  latency  of  a  task  i,  given  that 


•  Tasks  1  to  i-1  are  higher  priority. 

•  There  is  no  task  synchronization. 

•  Tasks  complete  before  the  end  of  their  periods. 

•  Task  i  starts  at  its  critical  instant. 


i-l 


•**+1  _  2 
7=1 


(1) 


The  recursion  can  be  started  by  setting  Xo  to  Sj,  and  it  ends  when  a  fixed  point  is  reached — 
that  is,  when  two  successive  iterations  yield  the  same  result.  Variations  of  Equation  (1)  can  be 
used  to  account  for  blocking,  to  handle  computation  past  the  end  of  the  period,  and  to  handle 
tasks  with  multiple  subtasks. 


Using  GRMA  for  Average-Case  Latency.  Strictly  speaking,  GRMA  was  developed  as  a 
worst-case  analysis  tool;  attention  was  focused  on  determining  conditions  leading  to  worst- 
case  latency.  However,  XAba  has  used  GRMA  as  an  average-case  analysis  tool.  To  understand 
average-case  latency,  we  need  some  additional  terminology: 

•  hyperperiod  -  The  hyperperiod  of  task  i  is  the  least  common  multiple  (LCM)  of  the  peri¬ 
ods  of  all  tasks  that  have  a  priority  greater  than  or  equal  to  task  i’s.  After  a  hyperperiod, 
the  pattern  of  execution  repeats. 

•  job  -  corresponds  to  each  instance  of  a  task’s  execution  during  the  hyperperiod 

•  job  latency  -  the  time  it  takes  from  the  moment  the  task  is  ready  to  run  to  the  moment  it 
finishes  executing.  Different  jobs  under  the  same  task  might  have  different  latencies. 

Since  the  pattern  of  execution  is  completely  defined  by  a  task’s  hyperperiod,  the  average  la¬ 
tency  of  task  i  can  be  determined  by  computing  the  average  job  latency  of  all  the  jobs  in  task 
i’s  hyperperiod.  A  variation  of  Equation  (1)  can  be  used  to  calculate  the  job  latency  for  each 
job  in  the  hyperperiod;  these  job  latencies  can  then  be  used  to  compute  the  average  latency. 


4  We  say  two  or  more  events  are  zero-phased  in  time  when  they  happen  at  the  same  moment  (i.e., 
there  is  no  time  delay  between  them). 
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2.3  Classical  Queueing  Theory 

Whereas  GRMA  focuses  on  the  case  in  which  interarrival  and  service  times  are  deterministic 
(or  at  least  bounded),  queueing  theory  focuses  on  the  case  in  which  interarrivals  and  service 
times  are  stochastic.  Basic  queueing5  problems  have  the  following  characteristics: 

•  Customers  (that  is,  events)  arrive  to  a  service  facility.  They  could  be  messages  arriving  to 
a  CPU  according  to  a  probability  distribution.  Due  to  its  analytical  tractability,  exponen¬ 
tial  interarrival  times  are  often  used.  We  limit  ourselves  to  exponential  distribution  for 
now. 

•  Each  customer  requires  a  certain  amount  of  time  in  the  service  facility  also  described  by 
a  probability  distribution.  We  limit  ourselves  to  a  constant  amount  of  time  for  now. 

•  In  many  cases,  queueing  models  include  more  than  one  service  facility.  We  limit  our¬ 
selves  to  one  service  facility  (that  is,  a  single  CPU). 

Key  Queueing-Theory  Result.  The  key  queueing  result  that  we  draw  on  is  the  following 
formula: 


E[W]  = 


1-/0 


A 


E[Sa2f 

2E[Sa]j 


+  E[Sa] 


(2) 


The  first  term  in  Equation  (2)  above  (known  as  the  Pollacek-Khinchin  expression  [Kleinrock 
75])  is  the  mean  queueing  time,  which  we  denote  by  E[Q]: 


E[Q]  = 


.1-/0  j 


2E[Sal 


(3) 


Therefore,  Equation  (2)  basically  says  that  the  mean  latency  is  the  mean  queueing  time  plus 
the  mean  service  time:  E[W]  =  E[Q]  +  E[Sa]. 


The  graph  in  Figure  1  shows  E[W]  as  a  function  of  p  (for  the  case  in  which  E[Ta]  =  200  and 
E[Sa]  varies  from  0  to  190).  Notice  that  for  low  values  of  p  (and  E[SJ),  E[Sa]  is  the  main 
contributor  to  average  latency.  However,  as  p  increases,  the  dominant  term  becomes  E[Q]. 


5  Queueing  theory  comprises  a  vast  and  rich  body  of  knowledge.  We  describe  only  the  most  basic 
queueing-theory  situations. 


6 
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Figure  1:  Average  Latency  for  a  Simple  Queue 

A  major  factor  in  a  queueing  system  is  the  queueing  time.  Queues  fill  up  due  to  bursts  of  ar¬ 
rivals  caused  by  variability  in  arrival  and  service  times. 
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3  Sporadic  Servers 


The  SSSA  [Sprunt  89]  was  invented  to  protect  periodic  events  with  hard  deadlines  from 
bursts  of  high-priority  stochastic  events  while  giving  high  priority  to  processing  stochastic 
events.  The  SSSA  both  limits  and  guarantees  a  certain  amount  of  execution  time  for  aperiodic 
requests  with  soft  or  hard  deadlines  in  a  hard  real-time  system  [Gonzalez  Harbour  91]. 

Implementations  of  the  SSSA  are  based  on  the  general  premise  that  a  server  (a  process  within 
an  operating  system  (OS)  or  a  thread  of  control  within  a  process)  that  handles  high-priority 
stochastic  events  will  execute  at  one  of  two  priorities:  foreground  (i.e.,  normal)  or  back¬ 
ground.6  An  aperiodic  task  will  execute  at  foreground  priority  if  the  sporadic  server  has  not 
exhausted  its  execution  budget  (Sss  in  Table  1  on  page  4).  If  the  budget  has  been  exhausted, 
the  aperiodic  task  is  restricted  to  background  priority.  A  sporadic  server  that  has  been  re¬ 
stricted  to  background  priority  is  not  restored  to  foreground  priority  or  reactivated  until  its 
execution  budget  is  replenished. 

The  execution  budget  is  a  nonzero  parameter  used  in  the  management  of  the  sporadic  server. 
This  budget  is  assigned  when  the  server  is  created  and  either  decreased  or  increased  over  the 
lifetime  of  the  sporadic  server  while  never  exceeding  its  initial  value.  The  budget  is  decreased 
each  time  the  sporadic  server  handles  an  event  in  foreground  priority.  Further,  each  time  the 
budget  is  decreased,  a  replenishment  event  is  scheduled  based  on  the  time  the  aperiodic  event 
arrived  to  the  sporadic  server  and  the  replenishment  period  (Tss  in  Table  1).  The  replenish¬ 
ment  period  is  also  a  nonzero  parameter  of  the  sporadic  server.  The  replenishment  event, 
then,  is  a  future  point  in  time  when  the  budget  for  the  sporadic  server  is  scheduled  to  be  in¬ 
creased. 

In  general,  the  SSSA  can  be  implemented  in  an  OS’s  scheduler  (e.g.,  kernel  mode)  [Shi  01]  or 
within  an  application  (e.g.,  user  mode)  [Gonzalez  Harbour  91].  When  implemented  in  an 
OS’s  kernel,  measures  of  actual  CPU  execution  time  used  by  a  process  or  thread  permit  more 
precise  accounting  and  finer  manipulation  of  the  sporadic  server’s  execution  budget  over  its 
lifetime. 

The  application-level  SSSA  makes  no  assumptions  about  support  for  sporadic  servers  in  any 
given  OS,  lending  easy  adaptation  to  a  variety  of  platforms.  Comparisons  between  the  appli- 


6  For  this  report,  foreground  priority  is  assumed  to  be  higher  than  the  ceiling  of  all  periodic  tasks; 
likewise,  background  priority  is  assumed  to  be  less  than  the  floor  of  all  periodic  tasks. 
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cation-level  sporadic  server  and  the  full-featured,  OS-supported  sporadic  server  show  that 
worst-case  performance  is  the  same  (except  for  additional  overhead)  and  the  average-case 
performance  can  be  almost  the  same  when  the  actual  process  or  thread  execution  time  ap¬ 
proaches  the  worst-case  estimation  [Gonzalez  Harbour  91]. 

Figure  2  is  an  example,  adapted  from  Gonzalez  Harbour’s  work  [Gonzalez  Harbour  91],  that 
depicts  the  general  behavior  of  an  application-level  sporadic  server. 


|  Replenishment 
|  Aperiodic  event 


Figure  2:  Example  of  a  Sporadic-Server-Controlled  Task 

In  this  example,  each  aperiodic  event  takes  5  units  of  time  to  be  serviced.  The  first  two  aperi¬ 
odic  requests  arrive  at  t= 5  and  t=  12  and  are  serviced  immediately  because,  at  f=5,  the  execu¬ 
tion  budget  of  the  sporadic  server  is  decreased  by  5  units  of  time.  That  decrease  still  leaves  a 
remaining  execution  budget  of  5  units  that  permits  the  sporadic  server  to  execute  at  fore¬ 
ground  priority.  Also  at  t=5,  a  replenishment  event  is  scheduled  for  t—23  (i.e.,  23  =  event  oc¬ 
curring  at  5  +  replenishment  period  18).  At  t=Y2,  the  execution  budget  is  again  reduced  by  5 
units  of  time,  the  replenishment  is  scheduled  for  r=30,  and  the  sporadic  server  can  still  exe¬ 
cute  at  foreground  priority.  After  t=12,  the  execution  budget  is  exhausted,  and  when  the  next 
aperiodic  event  arrives  at  f=18,  the  sporadic  server  is  restricted  to  execute  at  background  pri¬ 
ority.  The  additional  execution  budget  for  5  units  of  time  is  replenished  at  the  scheduled 
times  of  t= 23  and  f=30,  respectively,  for  the  first  two  requests,  thereby  restoring  the  execu¬ 
tion  budget  of  the  sporadic  server. 

To  implement  the  SSSAat  the  application  level  (i.e.,  without  explicit  OS-level  support),  only 
two  key  features  of  the  implementation  environment  are  necessary  : 

1.  some  form  of  synchronous,  interprocess,  or  interthread  communication 
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2.  the  ability  for  one  process  or  thread  to  read  and  change  another  process  or  thread  priority 

The  sporadic  server  manager,  or  SSmanager,  is  a  user-level  thread  that  operates  at  system 
high  priority.  The  purpose  of  the  SSmanager  is  to  manage  one  or  more  sporadic  server  tasks, 
or  SStasks,  each  of  which  processes  aperiodic  events.  An  aperiodic  task  can  be  converted  into 
an  SStask  by  including  two  synchronous  service  requests  to  the  SSmanager:  request  ( ) 
and  arm  ( ) . 

SSmanager .  request  ( )  is  a  method  called  by  the  SStask  as  soon  as  the  SStask  receives 
an  aperiodic  event  (see  Figure  3). 

//  SStask  handling  aperiodic  events 
Do  while  (not  done) 

SSmanager  .arm  (MJyThreadlD) 

//  Wait  for  aperiodic  event  request 

OS .wait  (event) 

SSmanager. request  (MytfhreadID,  Sa) 

//  Do  Aperiodic  Work 
done  =  doWork ( event ) ; 

End  Do 

Figure  3:  Pseudocode  for  SStask 

On  invocation,  SSmanager .  request  ( )  decides  whether  to  permit  the  SStask  to  run  at 
foreground  priority  based  on  the  budget  allocated  to  that  SStask  and  the  execution  time  re¬ 
quested  out  of  that  budget  (i.e.,  Sa).  If  sufficient  budget  is  available,  the  budget  for  the  SStask 
is  decreased  by  the  requested  amount,  a  replenishment  event  is  scheduled  for  a  later  time,  and 
the  SStask’s  priority  is  set  to  foreground  priority.  Otherwise,  the  request  for  an  execution 
budget  is  placed  on  a  pending  queue  of  requests,  and  the  SStask’s  priority  is  set  to  back¬ 
ground  priority  (see  Figure  4). 
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void  SSmanager: :arm(&SSTask)  { 

SetPriority  (SSTask.ID,  SYSTEM. MAX) 

) 

void  SSmanager: s reguest (ASSTask,  request_Sa)  { 

If  sstask. budget  >=  request_Sai  { 

Decrease  SStask. budget  by  request_Sa 
Replenishment  (SStask,  now( )+SStask.Tss,  Sa) 

SetPriority  (SSTask.ID,  SSTask. foreground) 

> 

Else  { 

SavePendingRequest  (SSTask,  request_Sa) 

SetPriority  (SSTask.ID,  SSTask. background) 

) 

End  if 

} 

Figure  4:  Pseudocode  for  SSmanager.request()  and  SSmanager. arm() 

SSmanager .  arm  ( )  is  also  used  by  the  SStask  to  communicate  that  the  processing  of  the 
aperiodic  event  is  complete  and  that  SStask  is  ready  to  process  another  aperiodic  request. 
SSmanager .  arm  ( )  then  places  the  SStask  at  a  system  high  priority,  allowing  the  latter  to 
wait  at  a  high  priority  for  the  aperiodic  event.  Placing  SStask  at  this  priority  is  necessary 
(specifically  for  the  application-level  SSSA)  to  allow  SStask  and  SSmanager  to  acquire  and 
compute  the  replenishment  origin  (i.e.,  now  ( )  +SStask .  Tss  in  Figure  4)  in  SSman¬ 
ager  .  request  ( )  based  on  a  time  as  close  as  possible  to  when  the  aperiodic  event  arrived 

at  the  SStask. 

SSmanager :  :replenishment_fcimer  C&SStask,  request_Sa)  { 

Increase  SStask. budget  by  request_Sa 

If  Get  Priority  ( sstask*  ID  ®=  SStask. background  and 
SStask.budget  >®  GetPendingRequest (SSTask) 

Decrease  SStask. budget  by  GetPendingRequest (SSTask) 

Replenishment  (SStask,  now()+SStask.Tss, 

GetPendingRequest (SSTask) ) 

SetPriority  ( SSTask . ID,  SSTask . foreground ) 

End  if 

} 

Figure  5:  Pseudocode  for  SSmanager.replenishment_timer() 

Replenishment  of  the  SStask’s  budget  occurs  in  the  SSmanager,  usually  via  an  OS-supported 
timer  event.  The  timer  handler  simply  increases  the  execution  budget  for  the  SStask  based  on 
the  last  honored  request  for  execution  time  (i.e.,  Sa).  Additionally,  the  timer  handler  will 
check  the  current  priority  of  the  managed  SStask.  If  it’s  at  background  priority,  the  SStask  is 

CMU/SEI-2004-TR-017 


still  processing,  in  background,  some  aperiodic  event  for  a  request  that  could  not  previously 
be  honored  due  to  the  lack  of  an  execution  budget.7  If  the  previous  request  can  now  be  hon¬ 
ored  (i.e.,  a  sufficient  budget  now  exists)  and  SStask  is  processing  in  background,  the  previ¬ 
ous  request  is  honored  following  the  same  steps  in  SSmanager .  request  ( ) . 


High-level  sequence  diagrams  covering  the  sequence  of  events  between  the  SStask,  SSman¬ 
ager,  and  the  host  OS  are  shown  in  Figure  6  (for  SSmanager .  request  ( )  and  SSman¬ 
ager  .  arm  ( ) )  and  in  Figure  7  (for  the  replenishment  timer). 


Figure  6:  UML  2.0  Sequence  Diagram  of  Application-Level  SSSA:  Request  and 
Arm 


7  If  the  SStask  is  at  foreground  priority,  there  is  no  need  to  increase  its  priority.  If  the  SStask  is  at 
system  high  priority,  the  SStask  is  armed  waiting  on  an  aperiodic  event  and  is  not  currently  proc¬ 
essing  one. 
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Figure  7:  UML  2.0  Sequence  Diagram  of  Application-Level  SSSA:  Replenishment 


4  Reasoning  About  the  Average  Latency  of 
Aperiodic  Tasks  Managed  by 
Application-Level  Sporadic  Servers 


The  previous  section  discussed  the  SSSA  for  blending  aperiodic  and  periodic  processing  in  a 
controlled  manner.  The  goal  of  this  section  is  to  show  how  queueing  theory  can  be  applied  to 
predict  the  average  latency  of  aperiodic  events  managed  by  a  sporadic  server. 

We  start  by  discussing  an  assembly  that  has  a  single  aperiodic  stream  of  events  with  interarri¬ 
val  times  governed  by  an  exponential  probability  distribution  and  constant  service  times. 

Such  a  situation  is  known  as  an  M/D/18  queueing  problem.  The  aperiodic  events  are  proc¬ 
essed  under  the  control  of  a  sporadic  server.  The  assembly  also  has  a  single  periodic  stream 
of  events.  The  sporadic  server  executes  at  the  highest  priority  and  allows  the  aperiodic  events 
to  execute  whenever  the  needed  budget  is  available.  Otherwise,  periodic  events  execute.  Ape¬ 
riodic  events  also  exploit  any  available  idle  time  left  over  from  the  periodics,  that  is,  back¬ 
ground  time. 

Assumptions.  In  summary,  here  are  the  governing  assumptions  for  this  section: 

•  There  is  a  single  stream  of  aperiodic  arrivals.  They  arrive  according  to  an  exponential 
distribution  with  mean  Ta— that  is,  if  X  is  a  random  variable  denoting  the  time  interval 
between  successive  arrivals,  the  cumulative  probability  distribution  is 

_  j_ 

Pr(X  <x)  =  \-e  T* 

•  The  execution  time  is  constant,  Sa. 

•  A  single  application-level  sporadic  server  is  used.  Its  budget  is  equal  to  the  constant  ape¬ 
riodic  service  time,  Sss=Sa.  Aperiodics  exploit  background  time,  if  it  is  available. 

•  The  assemblies  have  one  or  more  periodic  tasks  that  run  at  a  lower  priority  than  the  spo¬ 
radic  server.  (We  will  focus  initially  on  the  special  case  in  which  there  is  a  single  periodic 
task  with  execution  time  Sp  and  period  Tp.) 


8  M/D/1  is  conventional  queueing-theory  shorthand  denoting  queueing  systems  with  an  exponential 

interarrival  distribution — M  stands  for  "Markovian” — and  a  constant  execution  time  D  stands 
for  deterministic. 
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In  this  section,  our  goal  is  to  predict  the  average  latency  for  the  aperiodic  events  being  ser- 
viced  by  a  sporadic  server. 


4.1  Observations  About  Average  Latency  When 
Using  a  Sporadic  Server 

One  outcome  of  our  work  to  date  is  an  understanding  of  which  parameters  are  important  for 
controlling  average  latency.  Looking  at  Equation  (2),  it  is  evident  that  Sa  and  Ta  (which  are 
implicit  in  p  =  S/Ta)  are  important.  The  replenishment  period  (Tss)  and  the  budget  (Sss)  of  the 
sporadic  server  are  also  important.  The  utilization  of  the  periodic  events  (Up)  is  important, 
and,  perhaps  most  surprisingly,  the  period  of  the  periodic  events  (Tp)  is  also  an  important  pa¬ 
rameter. 

To  visualize  the  impact  of  varying  the  aforementioned  parameters,  we  ran  several  simulations 
and  plotted  the  results  shown  in  Figure  8.  The  situation  being  simulated  included  one  aperi¬ 
odic  and  one  periodic  task.  The  average  interarrival  interval  for  the  aperiodic  is  Ta=200;  the 
constant  execution  time  was  Sa=10.  The  period  of  the  periodic  task  is  different  for  each  curve 
(see  the  legend  in  Figure  8).  Each  curve  plots  the  average  latency  for  the  aperiodic  events, 
E[W],  as  a  function  of  periodic  utilization,  Up.  For  all  curves,  the  budget  and  replenishment 
period  of  the  sporadic  server  are  Sss=10  and  Tss=100,  respectively. 
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Some  observations  about  the  curves  in  Figure  8  follow: 

•  Given  a  period  of  the  periodic  (Tp),  the  average  latency  of  the  aperiodic  task  depends  on 
the  periodic  utilization.  The  intuition  for  that  statement  is  that  the  opportunity  to  run  in 
background  diminishes  as  the  utilization  of  the  periodic  task,  Up,  increases. 

•  The  curve  for  the  smallest  periodic  period  looks  like  a  standard  queueing  curve  (see 
Figure  1).  The  curve  with  the  largest  period  looks  like  it  aspires  to  be  a  straight  line,  sug¬ 
gesting  that,  as  the  period  of  the  periodic  decreases,  queueing-theoretic  effects  are  domi¬ 
nating.  As  the  period  increases,  we  are  seeing  a  linear  combination  of  end  effects. 

•  The  curves  start  and  eventually  reach  the  same  maximum.  The  intuition  for  that  statement 
is  that  when  the  periodic  utilization  is  0,  the  difference  in  period  is  immaterial.  Further¬ 
more,  all  the  curves  eventually  reach  a  point  at  which  there  is  no  longer  an  opportunity  to 
run  in  background.  This  point  may  be  reached  at  different  utilizations  for  different  curves 
(i.e.,  different  values  of  Tp). 

Next,  we  explore  in  more  detail  the  effect  of  varying  these  parameters  and  develop  detailed 
insight  for  some  of  the  cases  and  empirically  based  insight  for  other  cases.  First,  in  Section 
4.2,  we  look  at  the  special  case  when  periodic  utilization  is  zero;  effectively,  there  are  no  pe- 
riodics.  Then,  in  Section  4.3,  we  examine  the  other  extreme  where  the  utilization  of  the  peri- 
odics  is  sufficiently  high  so  that  the  aperiodic  only  executes  when  the  needed  budget  is  avail¬ 
able  from  the  sporadic  server.  Finally,  in  Section  4.4,  we  examine  the  case  in  which  the 
period  of  the  periodic  is  very  small  and  apply  queueing  theory  to  give  us  insight  into  the  na¬ 
ture  of  the  curves  in  Figure  8. 


4.2  Special  Case  of  No  Periodics 


When  there  are  no  periodics,  the  CPU  is  totally  available  to  the  aperiodic  task.  It  is  exactly 
the  same  as  a  classical  queueing  problem,  so  Equation  (2)  is  applicable  (which  is  duplicated 


below  for  convenience). 

P 


{  i7rn  2,) 


E[W]  = 


.1  ~P) 


E[S/] 
k2  E[Sa] 


(4) 


Using  the  example  from  Figure  8  where  Sa  =  10,  Ta  =  200,  and  p  =  Sa/Ta  =.05  and  substitut¬ 
ing  into  the  formula,  we  get  the  following  solution: 


E\W]  = 


^.05v 


V-95, 


10(A 


20 


+  10  =  10.26 


(5) 
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The  solution  above  is  very  close  to  what  is  shown  in  Figure  8 — 10.25  for  Up  -  0.  For  given 
values  of  Sa  and  Ta  (which  are  10  and  200  in  this  case),  all  the  curves  are  “anchored”  at  this 

point. 


4.3  Special  Case  of  No  Background 

When  the  periodic  tasks  consume  enough  of  the  CPU  such  that  there  is  no  background  avail¬ 
able  for  the  aperiodic  events  to  exploit,  all  of  the  aperiodic  task  s  processing  must  be  per¬ 
formed  within  the  budget  of  the  sporadic  server.  In  our  example  (that  is,  Sss=10  and  Tss=100), 
only  10  ms9  of  time  running  at  foreground  priority  is  available  every  100  ms  through  the  spo¬ 
radic  server. 


To  help  explain  further,  we  provide  the  following  analogy.  Imagine  customers  queueing  up  to 
a  teller’s  window  in  a  bank.  In  the  no-periodics  case,  the  teller  continuously  processes  cus¬ 
tomer  requests.  In  the  no-background  case,  the  teller  takes  care  of  one  customer  (recall  that 
the  customer  request  exactly  matches  the  sporadic  server’s  budget  of  10  ms)  and  then  does 
other  non-customer  work  (e.g.,  paperwork)  for  90  ms,  while  the  next  customer  impatiently 
waits.  From  the  point  of  view  of  customers  in  the  queue,  each  customer  seems  to  be  taking 
100  ms.  (Let’s  pretend  that  customers  in  the  queue  cannot  distinguish  between  real  customer 
work  and  paperwork.)  The  only  saving  grace  is  that  customers  are  pleasantly  surprised  to  find 
out  that  once  they  reach  the  teller,  their  request  only  takes  10  ms.  Consequently,  from  the 
point  of  view  of  customers  in  the  queue,  Sa  =  100;  from  the  point  of  view  of  the  customer 
being  serviced,  Sa  =  10.  To  reflect  this  in  the  formula,  we  denote  the  service  time  from  the 
queueing  perspective  as  Sq,  service  time  from  the  server  perspective  as  Ss,  and  traffic  inten¬ 
sity  from  the  queueing  perspective  as  pq.  This  more  general  formula  is 


E[W]  = 


1  ~P, 


E[Sj  l 
2E[Sg]> 


+  E[Ss] 


(6) 


Again,  using  the  example  from  Figure  8  where  Ss  =  10,  Sq  =  100,  Ta  -  200,  and  pq  -  Sq/Ta  -.5 
and  substituting  into  the  formula,  we  get  the  following  solution: 


-"■(IMH 


(7) 


The  solution  above  is  also  very  close  to  what  is  shown  in  Figure  8 — 62.4  ms. 


9  Using  milliseconds  is  arbitrary  but  a  little  more  concrete  than  saying  “units  of  time.” 
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4.4  Special  Case  of  Continuous  Background 

The  two  previous  sections  discussed  two  special  cases:  Up=0  and  Up=.9,  no  periodics  and  no 
background,  respectively.  Our  next  challenge  is  to  understand  the  “curves”  between  these  two 
extremes.  We  chose  to  study  what  we  have  been  calling  the  “continuous  background”  case. 
This  case  is  unrealistic  but  useful  because  it  reveals  much  of  the  problem’s  queueing- 
theoretic  structure. 

When  the  sporadic  server  has  exhausted  its  budget,  the  only  way  for  aperiodics  to  execute  is 
in  background.  If  Sp=5  and  Tp=10,  background  becomes  available  in  chunks  of  5;  if  Sp=.5  and 
Tp=l,  background  becomes  available  in  chunks  of  .5;  if  Sp=.05  and  Tp=.l,  background  be¬ 
comes  available  in  chunks  of  .05,  and  so  forth.  The  smaller  the  period,  the  more  “continu¬ 
ously”  background  is  available.  Continuing  to  reduce  Sp  and  Tp  in  this  manner  results  in 
background  being  very  frequently  available  in  infinitesimal  quantities — a  situation  we  call 
continuous  background.  In  this  case,  background  processing  is  equivalent  to  being  continu¬ 
ously  processed  in  a  degraded  processor.  For  example,  when  Up=.5,  background  processing 
in  the  continuous  case  is  equivalent  to  executing  in  a  CPU  that  is  half  the  speed  of  a  full 
processor.  This  equivalence  to  a  degraded  processor  is  what  makes  this  an  interesting  and 
illuminating  special  case.10 

A  Sample  Timeline.  It’s  helpful  to  consider  a  sample  timeline  to  see  the  different  types  of 
time  experienced  by  aperiodic  events  in  this  case  of  continuous  background. 

Immediately  prior  to  the  beginning  of  the  timeline  shown  in  Figure  9,  assume  that  the  proces¬ 
sor  is  idle  and  the  sporadic  server  is  loaded  with  its  entire  budget  of  execution  time.  When  the 
first  aperiodic  event  occurs  at  t  =  100,  it  is  immediately  served  by  the  sporadic  server.  We 
assume  that  Sss  =  Sa  =  20,  Tss  =  145,  Up=.5  and  that  Tp  is  infinitesimally  small.  Since  the  spo¬ 
radic  budget  is  equal  to  the  aperiodic  service  time  (remember  we  constrain  our  assemblies  to 
adhere  to  this  restriction),  the  aperiodic  that  starts  at  t=100  completes  within  the  sporadic 
server’s  budget  of  20  at  t=120. 


10  On  more  than  one  occasion  when  we  described  this  special  case,  we  were  asked,  “What  about  the 
deadlines  of  the  periodic  processes,  aren’t  they  being  missed?”  Or,  “If  a  rate  monotonic  priority 
assignment  is  being  used,  why  does  the  sporadic  server  execute  at  a  higher  priority?”  First,  we 
could  pretend  that  the  deadlines  are  very  long  and  we  are  using  a  deadline  monotonic  priority  as¬ 
signment.  However,  we  are  actually  ignoring  the  periodics.  The  whole  point  of  considering  this 
case  is  to  gain  some  understanding  of  the  curves  in  Figure  8.  In  fact,  by  treating  background  proc¬ 
essing  as  a  degraded  processor,  the  periodics  effectively  disappear. 
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Replenishment 


Replenishment 


Aperiodic  arrivals 


100  120  140  155  195 


l 


“Backlog  time”  due  to 
backlog  of  periodics 


225  245  255  265 


n  i 

“Backlog”  time  due  to 
backlog  of  periodics 

Processing  with 

Degraded  background 

Processing  with 

sporadic  server 

processing 

sporadic  server 

Figure  9:  Sample  Timeline 

“Backlog”  Time.  While  the  sporadic  server  is  working,  a  backlog  of  undone  periodic  work  is 
accumulating.  At  t=120,  this  backlog  is  equal  to  Sa*Up  =  20*. 5  =  10.  However,  while  con¬ 
tinuously  working  on  this  backlog  of  10  units  of  periodic  work,  more  undone  periodic  work 
accumulates— in  this  case,  10*.5.  This  accumulation  continues  until  the  work  is  finished.  The 
following  expression  is  how  long  it  takes  from  the  time  the  aperiodic  event  arrives  at  t— 100 
until  both  it  and  the  backlog  have  completed: 


+Saup+ sau2p + saul + Sau; + •  - = - 


■um 


(S) 


For  our  sample  timeline,  Sa/(1-Up)  =  20/(l-.5)  =  40,  which  means  the  backlog  interval  com¬ 
pletes  at  time  t=140. 

Equation  (8)  gives  us  insight  into  how  to  generalize  the  no-background  result.  Recall  that  for 
the  no-background  case,  Sq  =  Tss.  However,  the  more  general  result  for  arbitrary  values  of  Up 
is  Sq  =  Sa/(1-Up).  Notice  that  since  Sa  =  Sss,  when  Up  =  1-Sss/Tss  (that  is,  the  periodic  utiliza¬ 
tion  is  1  minus  the  sporadic  server  utilization),  E[Sq]  =TSS 

Degraded  Background  Processing.  Next,  we  focus  our  attention  on  the  block  of  processing 
that  starts  at  t=155.  That  block  represents  an  aperiodic  arrival  that  is  completely  executed  in 
background.  In  effect,  it  is  completely  executed  in  a  degraded  processor.  In  this  example,  Up 
=  .5.  As  a  result,  the  processor  is  degraded  by  50%,  and  consequently,  we  would  expect  the 
20  ms  service  time  to  take  40  ms.  In  general,  we  would  expect  the  Sa  service  time  to  take 
Sa/(1-Up).  Notice  that  the  degraded  service  time  (when  executing  completely  in  background) 
is  equal  to  the  service  time  plus  backlog  time  when  executing  within  a  sporadic  server. 
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“Hybrid”  Processing.  Next,  we  consider  the  processing  that  starts  at  time  t=225  in  Figure  9. 
In  this  case,  service  starts  in  background.  Then,  when  it  is  partially  complete,  the  sporadic 
server’s  budget  is  replenished,  and  the  remainder  of  the  processing  is  done  in  the  sporadic 
server.  The  case  depicted  by  the  timeline  shows  that  half  of  the  service  is  completed  in  back¬ 
ground,  and  half  is  completed  in  the  sporadic  server.  Note  that  we  are  studying  the  applica¬ 
tion-level  sporadic  server,  so  whatever  budget  is  not  used  is  lost.  In  our  example,  five  units  of 
time  remain  to  be  processed  in  the  sporadic  server.  Therefore,  the  five  units  of  remaining  ca¬ 
pacity  are  lost. 

The  background  processing  requires  (.5*Sa)/(l-Up),  and  the  sporadic  server  and  backlog  time 
also  require  (,5*Sa)/(l-Up).  As  a  result,  the  total  is  S^l-Up);  this  is  true  regardless  of  the  frac¬ 
tion  that  completes  in  background. 


4.4.1  Computing  Average  Queueing  Time  (E[Q]) 

Above,  we  argued  that  it  does  not  matter  whether  an  aperiodic  arrival  starts  and  completes 
within  the  sporadic  server  (i.e.,  the  execution  budget  was  sufficient  to  process  the  aperiodic 
event),  gets  processed  completely  in  background  (i.e.,  no  execution  budget  is  available),  or  is 
a  hybrid  (i.e.,  the  execution  budget  was  replenished  prior  to  completion  of  the  aperiodic 
event).  The  customers  in  the  queue  always  see  a  delay  of  Sa/(1-Up)  for  each  customer  served. 
This  fact  enables  us  to  compute  the  average  time  in  the  queue,  which  under  a  heavy  load  is 
usually  a  major  contributor  to  average  latency  (see  Figure  1  on  page  7).  To  predict  the  queue¬ 
ing  time,  we  can  use  Equation  (3)  as  follows: 


E[Q]  = 


l-P, 


E[S]  ] 

2  E[Sq\j 


,  where  Sq=Sa/(l-Up)  and  pq=S/Ta 


(9) 


For  the  situation  in  which  Tp=l  and  Ta=50,  250,  and  500,  Figure  10  shows  6  curves;11  three 
curves  show  predicted  queueing  time  and  three  show  actual  results  from  a  simulation. 


1 1  Note  that  the  predicted  and  actual  lines  in  Figure  10  are  so  close,  their  respective  curves  are  diffi¬ 
cult  to  distinguish. 
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E[Q]  vs  Up 


— Prediction  Ta=50 
— Prediction  Ta=250 
-o  Prediction  Ta=500 

- Actual  Ta=50 

- Actual  Ta=250 

- Actual  Ta=500 


Figure  10:  Predicting  E[Q] 

4.4.2  Computing  Average  Service  Time  (E[Ss]) 

Figure  11  below  highlights  the  actual  service  times  for  the  timeline  shown  above  in  Figure  9. 
Note  that  while  Sq  in  Equation  (6)  is  the  same  regardless  of  whether  an  arrival  is  processed  in 
the  sporadic  server,  in  background,  or  as  a  hybrid,  the  actual  execution,  Ss,  varies  depending 
on  the  situation. 


Figure  1 1:  Differing  Service  Times  for  the  Aperiodic  Arrivals 

The  service  time  for  the  arrival  serviced  at  high  priority  by  the  sporadic  server  is  Sa.  The  arri¬ 
val  that  is  executed  completely  in  background  has  an  execution  time  of  Ss  = 

Sa  =  Sa/(  1  -Up).  The  arrival  that  executes  as  a  hybrid  (where  a  fraction,  a,  of  its  execution 

time  completed  in  background  and  the  rest  with  the  sporadic  server)  has  an  execution  of  Ss  - 
oSa+(l-a)Sa. 

These  differing  service  times  pose  a  challenge  for  deriving  an  exact  formula  for  predicting 
average  latency.  The  challenge  is  to  determine  the  probability  associated  with  each  case 
above. 
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Overall  Approach.  The  three  different  situations  shown  in  Figure  11  above  can  be  distin¬ 
guished  by  where  their  busy  periods12  start  relative  to  when  replenishment  occurs  and  then  by 
the  length  of  their  busy  periods.  For  example,  if  the  following  conditions  are  true,  the  busy 
period  will  consist  of  one  service  time  of  duration  Sa  (for  the  first  job,  which  executed  within 
the  sporadic  server)  followed  by  n-1  service  times  of  length  Sa  : 

•  Replenishment  occurs  during  an  idle  period. 

•  Sometime  later,  a  busy  period  starts. 

•  The  busy  period  has  n  jobs. 

•  The  busy  period  completes  before  the  next  replenishment  time. 

Another  busy  period  might  start  before  the  point  of  replenishment,  continue  past  the  point  of 
replenishment,  and  have  a  duration  less  than  T^.  In  this  case,  the  busy  period  might  comprise 
n-1  jobs  of  length  Sa  and  one  job  of  length  aSa  +  (1  -  a)Sa  (where  a  <  1 ). 


E[Ss]  depends  on  the  amount  of  time  from  the  beginning  of  the  busy  period  until  the  point  of 
replenishment  (or  what  we  call  the  time  to  replenishment)  and  on  the  length  of  the  busy  pe¬ 
riod.  Because  of  that,  our  approach  is  to  determine  the  distribution  function  describing  the 
time  to  replenishment  for  the  start  of  a  busy  period  and  use  that  value  in  conjunction  with  the 
distribution  function  for  the  length  of  the  busy  period  as  the  basis  for  computing  E[Ss]. 

Let  Tr  be  the  random  variable  denoting  the  time  to  replenishment  at  the  beginning  of  busy 
periods.  Our  goal  is  to  compute 

E[Ss]  =  jE[Ss\Tr  =  t]dFTr(t )  (10) 

[0  Jss] 

where  E[Ss  |  Tr=t]  is  the  conditional  expectation  of  Ss,  given  that  the  time  to  replenishment  is 
Tr=t  and  FTr(t)  is  the  cumulative  distribution  function  (CDF)  for  the  time  to  replenishment. 

Given  that  Tr  can  be  neither  negative  nor  greater  than  the  replenishment  period,  t  can  only 
take  values  in  the  interval  [0,  Tss].  The  CDF  is  the  probability  that  Tr  is  less  than  or  equal  to  t 
(represented  as  Pr(Tr<t)  ). 

To  gain  insight  into  the  nature  of  the  distribution  of  Tr,  we  ran  several  simulations  and  plotted 
the  histogram  shown  in  Figure  12  for  one  of  them.  The  parameters  for  this  simulation  were 
Sss=10,  Tss=100,  Up=.60,  Sa=10,  Ta=200,  and  Tp=l. 


12  A  busy  period  is  a  continuous  interval  of  time  during  which  the  server  (or  processor)  is  busy. 
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Each  bar  except  the  first  bar  represents  the  average  probability  density  over  the  interval  cal¬ 
culated  by  taking  the  proportion  of  samples  falling  within  the  interval  divided  by  the  length 
of  the  interval.  The  first  bar  is  the  proportion  of  samples  whose  busy  period  starts  at  Tr=0. 


o 


10 

£  “1 
o 


i^Hl  Pr(Tr=0) 


Tr 


Figure  12:  Histogram  ofTr 

Notice  that  Tr  has  what  appears  to  be  a  uniform  density  between  Tr>0  and  approximately  75, 
has  a  much  higher  density  (approximately  0.716)  at  Tr=0,  and  has  a  density  that  tails  off  from 
75  to  100.  Therefore,  it  appears  that  fTr(t),  the  density  function  of  time  to  replenishment,  has 
the  form 


au0(t)  for  t  =  0 

- -  for  t  in  (0 ,T„  -h) 

T„  -h 


[d (0  for  t  in  [Tss  - h,Tss ] 


(ID 


where  a  is  a  constant  and  uo(t)  is  the  Dirac  delta  function  [Kleinrock  75].  This  result  moti¬ 
vated  us  to  break  Equation  (10)  into  two  terms:  one  for  Tr=0  and  one  for  Tr>0  as  shown  in 
Equation  (12)  below. 

E[Ss ]  =  E[Ss  |  Tr  =  0]Pr(7r  =  0)  +  j E[Ss  \ Tr  =  t]fTr ( t)dt 

( OJss ] 


Evaluating  Pr(Tr=0).  To  understand  how  to  compute  Pr(Tr=0),  consider  Figure  13  below. 
The  x-axis  is  time,  and  the  y-axis  is  time  to  replenishment  (Tr).  Time  to  replenishment  starts 
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at  Tr=0  and  then  stays  at  that  level  until  a  busy  period  starts  due  to  an  aperiodic  arrival.  At 
that  moment,  the  sporadic  server’s  budget  is  consumed,  and  the  next  replenishment  is  sched¬ 
uled  to  occur  one  replenishment  period  later,  making  Tr=Tss.  Tr  then  decreases  at  a  rate  of  one 
until  it  reaches  zero,  and  then  replenishment  occurs.  Replenishment  can  occur  either  during  a 
busy  period— a  dark  region  on  the  bottom  timeline— or  during  an  idle  period.  If  it  occurs  dur¬ 
ing  a  busy  period,  Tr  is  once  again  immediately  set  equal  to  Tss  and  starts  to  decrease.  If  re¬ 
plenishment  occurs  during  an  idle  period,  Tr  remains  at  zero  until  the  next  arrival  occurs. 
When  that  happens,  Tr  is  set  equal  to  Tss  and  starts  decreasing. 


■ 

a 

SB 

B 

■ 

B 

SB 

TIT 

n 

TIB 

Figure  13:  Time  to  Replenishment  and  Busy  Periods 

The  question  is,  how  do  we  characterize  the  proportion  of  time  in  which  the  system  is  in  the 
Tr=0  state?  First,  note  that  several  busy  periods  can  occur  during  the  period  of  time  from 
Tr=Tss  to  Tr=0.  In  fact,  our  current  analysis  depends  on  the  replenishment  period  being  large 
enough  for  several  busy-idle  cycles  to  occur  during  one  replenishment  period.  However,  at 
most,  one  of  those  busy  periods  can  be  preceded  by  an  interval  in  which  Tr=0.  And  such  an 
interval  (of  Tr=0)  only  occurs  when  the  previous  replenishment  occurs  during  the  idle  inter¬ 
val  that  immediately  precedes  the  busy  period. 

To  compute  Pr(Tr=0),  we  will  associate  one  busy  period  with  each  time  a  replenishment  oc¬ 
curs.  If  replenishment  occurs  during  an  idle  period,  we  will  associate  it  with  the  first  busy 
period  after  the  replenishment.  If  the  replenishment  occurs  during  a  busy  period,  that  period 
will  be  associated  with  it  (see  Figure  13  above).  Therefore  the  interval  denoted  by  X*  in 
Figure  13  always  begins  during  (or  at  the  beginning  of)  a  busy  period  associated  with  a  re¬ 
plenishment. 

Tr=0  occurs  when  a  busy  period  has  a  replenishment  associated  with  it  and  when  the  replen¬ 
ishment  occurs  during  an  idle  interval.  Assuming  these  two  events  are  independent,  Pr(Tr=0) 
=  Pi*Pr  where  Pr  =  Pr(the  busy  period  is  associated  with  a  replenishment)  and  pi  = 
Pr(replenishment  occurs  during  an  idle  period).  To  calculate  pi  and  Pr,  we  will  use  some  re¬ 
sults  from  renewal  theory. 

A  Result  from  Renewal  Theory.  A  renewal  process  is  defined  as  a  stochastic  process  that 
counts  the  number  of  arrivals  of  events,  N(t),  that  occur  in  the  interval  [0,t]  where  the  time 
between  arrivals  is  determined  by  a  sequence  of  nonnegative,  independent,  identically  dis¬ 
tributed  random  variables  {Xj,  i=l,  2, . . . }.  Xi  is  the  time  between  arrivals  i-1  and  i  [Ross  96]. 
N(t)  can  then  be  defined  in  terms  of  Xj. 
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(13) 


iV(0  =  rnax{n|]rX,.  <f} 

1=1 

An  alternating  renewal  process  is  defined  as  a  sequence  of  random  vectors  (Zj,  Yj)  where  Zi 
occurs,  followed  by  Yi,  followed  by  Z2,  followed  by  Y2,  and  so  on.  You  can  think  of  a  system 
as  being  in  one  of  two  states:  it  is  in  state  “on”  for  an  interval  of  length  Zu  followed  by  state 
“off”  for  an  interval  of  lengthY,,  and  so  forth.  The  Z*s  are  independent  and  identically  dis¬ 
tributed,  as  are  the  YjS.  We  will  use  the  following  theorem  from  Ross  where  Pon(t)  is  the 
probability  that  the  system  is  “on”  at  time  t  [Ross  96]. 


Theorem:  If  Pon(t)  =  Pr(system  is  on  at  time  t)  and  E[Zj+Yj]  is  finite  (and  the  distribution  of 
Zi+Yj  is  nonlattice13)  then 


m,] 

EPJ  +  EIZJ 


(14) 


This  theorem  says  that  the  limiting  probability  the  system  will  be  “on”  is  equal  to  the  propor¬ 
tion  of  time  that  it  is  “on”  during  an  average  on-off  cycle. 


Calculating  pi.  We  can  view  an  on-off  cycle  as  an  idle  interval,  Ii,  followed  by  a  busy  period, 

Bj.  If  we  consider  the  idle  interval  as  “on  time”  and  use  the  above  theorem,  we  get  the  follow¬ 
ing  equation: 

=  £[/,!_  (15) 

Fl  E[B, ,]  +  £[/,] 

Calculating  pR.  Recall  that  Pr  is  the  probability  that  a  busy  period  is  associated  with  replen¬ 
ishment.  We  can  define  a  renewal  as  the  time  at  which  the  sporadic  server’s  budget  is  con¬ 
sumed  and  Xj  (Figure  13)  as  the  time  between  such  renewals.  To  compute  pR,  we  must  deter¬ 
mine  the  average  number  of  cycles  that  can  occur  during  an  interval  between  renewals,  where 
a  cycle  is  C,=B,+/,: 


mi+EUj]  (16) 

P“  E[X,] 

If  the  cycle  associated  with  replenishment  is  thought  of  as  an  on  interval  and  the  other  cy¬ 
cles  during  Xj  are  thought  of  as  an  “off  interval,”  Equation  (16)  can  be  viewed  as  another  ap¬ 
plication  of  Equation  (14).  Therefore,  to  determine  pR,  we  first  need  to  determine  E[Xj]. 


13  A  nonnegative  random  variable  is  said  to  be  lattice  if  it  takes  on  values  only  at  points  that  are  mul¬ 
tiples  of  some  nonnegative  number,  d  [Ross  96]. 
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Calculating  E[XJ.  Note  two  things: 

1 .  Xj  is  equal  to  Tss  if  the  i*  replenishment  occurs  during  a  busy  period. 

2.  Xj  is  equal  to  Tss  plus  the  remaining  portion  of  an  already  started  idle  period,  if  the  i* 
replenishment  occurs  during  an  idle  period. 

Therefore,  we  need  to  understand  the  distribution  of  the  remaining  portion  of  idle  time  to  de¬ 
termine  the  distribution  for  Xj.  I  denotes  idle  time.  Since  we  assume  that  the  arrival  distribu¬ 
tion  is  exponential  and  the  exponential  distribution  is  memoryless,14  the  idle  time  distribution 
must  also  be  exponential  [Kleinrock  75]. 

Let  IR(t)  denote  the  remaining  idle  time  at  time  t.  This  time  is  known  as  the  residual  time  or 
the  forward  recurrence  time. 

The  limiting  distribution  for  IR(t)  is 

Pr(/„£*)  =  |  F,  <g)ifl  £[/]  (17) 

0 

where  F,  (x)  =  1-Frfx)  [Ross  96].  Since  I  is  exponentially  distributed  with  mean  Ta,  the 
“memoryless”  property  of  an  exponential  distribution  would  suggest  that  /Ris  also  exponen¬ 
tially  distributed  with  the  same  mean.  Using  Equation  (17)  to  compute  the  distribution  of  IR 
confirms  this. 

Using  the  distribution  of  IR  and  letting  pB  =  1-pi  we  can  compute  the  distribution  for  X,  as  fol¬ 
lows: 

Pr(X,  <  x)  =  Pr(X,  <  x  |  Busy ) pB  +  Pr(X,.  <  x  |  Idle)p, 15  for  x  >  Tss 

Pr(X,  <  x)  =  0  forx<Tss 

Since  we  know  that  Xj  is  Tss  when  replenishment  occurs  during  a  busy  period,  the  first  term  is 
simply  l*pB.  The  second  term  represents  the  case  in  which  replenishment  occurs  during  an 
idle  interval  and  comprises  Tss  plus  some  remaining  idle  time.  Therefore 

Pr(X,  <x)  =  pB+  Pr(TiS  +  IR< x)p,  for  x>Tss  (18) 

Figure  14  below  shows  the  shape  of  the  cumulative  distribution  function,  Fxi(t),  for  Xj. 


14  Memoryless  means  that  the  amount  of  idleness  that  has  already  occurred  does  not  affect  how  much 
idleness  is  left  for  any  given  idle  interval. 

15  Busy  means  replenishment  during  a  busy  period,  and  idle  means  replenishment  during  an  idle  pe¬ 
riod. 
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Figure  14:  CDF  for  X, 

The  expectation  of  X*  can  be  calculated  by  conditioning  on  whether  Xj  occurs  in  an  idle  or 
busy  period,  that  is 

E[Xi)  =  E[Xi\Busy)pB+E[Xi\Idle]pl  =  TssPb+(Tss+E[Ir])Pi  =  Tss+E[Ir)Pi  (19) 

Substituting  the  expression  for  E[X;]  from  Equation  (19)  into  Equation  (16)  results  in  this 
equation: 

_  milELl  (20) 

R  Tss+E[Ir]Pi 

which  is  equal  to  the  probability  that  a  cycle  is  associated  with  a  replenishment.  Since 
Pr(Tr=0)  =  pi*pR,  the  following  equation  applies: 

on 

Tss  +  EUr\Pi 

Evaluating  E[Ss  |  Tr=0].  Just  as  a  reminder,  our  goal  is  to  use  Equation  (12)  to  compute 
E[Ss].  We  are  still  calculating  the  first  term  of  Equation  (12).  We  have  worked  out  Pr(Tr=0), 
and  now  we  turn  our  attention  to  E[Ss|  Tr=0]. 


To  compute  E[Ss|  Tr=0],  we  condition  on  the  number  of  arrivals  in  a  busy  period.  In  our  case, 
the  distribution  for  the  number  of  arrivals,  BP,  in  an  M/D/1  busy  period  is  the  following 
[Kleinrock  75]: 


Pr  {BP  =  n)  = 


jnpq) 

n\ 


n- 1 


-e~np'  where  pq  =-f- 

*0 


(22) 


16  We  are  justified  in  using  this  since  the  previous  section  argued  that,  from  a  queueing  perspective, 
Sq  is  equal  to  S,/(1-Up)  regardless  of  whether  it  executes  within  a  sporadic  server,  in  background, 
or  as  a  hybrid. 
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When  Tr=0,  the  busy  period  always  starts  with  an  arrival  that  is  “greeted  by”  a  fully  loaded 
sporadic  server.  This  first  arrival  will  have  a  service  time  of  Sa.  Depending  on  how  large  Tss  is 
relative  to  Sa ,  the  busy  period  continues  with  some  number  of  additional  arrivals  that  execute 

A 

in  background  and  consequently  have  service  times  ofS0 .  If  the  busy  period  is  long  enough, 
it  might  contain  one  or  more  “hybrid”  service  times  as  well. 

For  now,  we  will  ignore  the  hybrid  services  (in  which  case,  our  estimate  will  be  on  the  high 
side).  Later,  we  will  show  an  algorithm  that  accounts  for  the  hybrid  case.  The  following  ex¬ 
pression  is  a  pessimistic  approximation  of  the  duration  of  a  busy  period  of  length  i,  given  that 
Tr=0: 

S.+«- l)S„  C3> 

This  equation  is  pessimistic  since  it  approximates  a  hybrid’s  execution — which  is 
aS  +  (1  -  a)Sa  — using  simply  Sa .  We  use  this  approximation  to  compute  an  approxima¬ 
tion  for  E[Ss|  Tr=0]. 

Given  a  very  large  number  of  busy  periods  (denoted  as  N)  and  the  strong  law  of  large  num¬ 
bers  [Ross  96],  there  are  approximately  Pr(BP=i)*N  busy  periods  of  length  i  [Cinlar  97]. 

Equation  (23)  expresses  that  for  each  busy  period  of  length  i,  there  is  one  arrival  with  a  ser¬ 
vice  time  of  Sa  and  i-1  with  service  times  of  S  a .  Therefore 

YJMBP  =  i)N[Sa  +  (i-l)Sa] 

£[S,|rr=0]  =  -^ - - - 

£Pr(BP  =  0(W) 

i=i 

which  reduces  to 


£pr(BP  =  /)[50+(i-l)SJ 

as,|r,-°]--'  w - — 

where  Pr(BP=i)  is  defined  in  Equation  (22)  and  E[BP]=l/(l-p). 

Therefore,  an  approximation  for  the  first  term  in  Equation  (12)  is 

f?r(BP  =  i)[Sa+(i-l)Sa] 


(24) 


E[Ss  |  Tr  =  0]Pr(7r  =  0)  = 


Mmj+Euj) 

Ps s  +  B\1r  ]p/ 


\  ss 


i=l 


E[BP ] 


(25) 
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Calculating  J  E[Ss  |  Tr  =  t]fTr  ( t)dt .  Our  next  step  is  to  consider  the  case  in  which  Tr  is 

(0  Jss] 

greater  than  zero.  To  do  this,  we  need  to  determine  the  cumulative  distribution  function  for 
Tr,  FtM 


Recall  that  Tr  is  a  random  variable  denoting  the  time  to  replenishment  for  the  beginning  of  a 
busy  period.  To  compute  Pr(7r  <  /) ,  we  condition  on  whether  Tr  equals  zero  or  is  greater 

than  zero.  Recall  that 

Pr(7>  <t)  =  Pr(7>  <  1 1  Tr  =  0)  Pr(7r  =  0)  +  Pr (Tr  <t\Tr>  0)(1  -  Pr(T r  =  0))  (26) 

The  first  term  reduces  to  Pr(Tr=0);  Equation  (21)  addresses  this  case. 

Tr>0  occurs  when  XA,17  the  time  since  the  last  renewal  (known  as  the  age  or  the  backward 
recurrence  time),  is  less  than  Tss.  Therefore,  Pr(7r  <  t  \  Tr  >  0)  is  equivalent  to 

Pr(7r  <t\XA  <TSS),  however 

Pr  (Tr  <t\XA<Tss)  =  ?t(Tss -XA<t\XA<TJ  =  l-Pr(XA  <  Tss  -t  \  XA  <  Tss)  (27) 

Since  the  limiting  distributions  of  the  forward  and  backward  recurrence  times  of  a  renewal 
process  are  the  same,  we  can  use  Equation  (17)  to  compute  Pr(XA  <t)  [Ross  96]: 


0 


(28) 


Using  Equation  (28)  and  conditional  probability  and  referring  to  Figure  14 

jFx(£)df  jMf 

Pr(Xa<f|Xa<T„)  =  i - :± - =  — 

|  F*  (£><*£  [Wf  “ 


Therefore 

Pr  (Tr  <t\Tr>0)  =  l-Pr(XA  <  Tss -t  \  XA  <  Tss)  =  l-~r^  = 

*ss  *ss 

which  is  a  uniform  distribution  over  [0,  Tss].  The  cumulative  distribution  function  for  Tr  is 


17  The  letter  “A”  in  XA  stands  for  “age.”  If  one  considers  a  renewal  to  be  a  birth,  XA  represents  the 
time  since  the  last  renewal.  This  should  not  be  confused  with  Xj,  which  represents  the  time  be¬ 
tween  successive  renewals. 
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and  the  density  function  for  Tr  is 


fTr  (i t )  =  =  Pr (Tr  =  0 )u0  (t)  +  -  ^  0)- 

dt  *  (PC 


which  is  similar  in  form  to  Equation  (11). 


This  results  in 

\E[Ss\Tr  =  t]fTr(t)dt=  J  E[Ss\Tr  =  t]1~VT^r~°^dt  (30) 

(0  Jss]  (09Tss]  5S 

Accounting  for  “blackout.”  Figure  12  showed  that  Tr  is  not  actually  uniformly  distributed 
over  the  entire  interval  [0,  TJ  but  instead  is  uniformly  distributed  over  the  shorter  interval  [0, 
Tss-h],  This  distribution  makes  sense  since  each  renewal  occurs  either  during  or  at  the  begin¬ 
ning  of  a  busy  period.  By  definition,  the  next  busy  period  cannot  begin  until  the  current  one 
ends,  resulting  in  a  “blackout”  period,  H,  for  Tr  from  T$s-H  to  Tss.  Let  H  be  a  random  variable 
denoting  the  duration  of  this  blackout  period. 

Assume  that  H=h.  Due  to  this  blackout  period,  Pr(7r  <t|7r>0)  is  not  actually  equivalent 
to  Pr(7>  <t\XA  <TSS).  Rather,  it  is  equivalent  to  Pr(7V  <t\h<XA  <TSS).  This  differ¬ 
ence  changes  Equation  (29)  to 

J  Fjibdf  jldf 

Pr(X,<(|A<X,<7-„)  =  ^ - ■*-_ - =  —  (3D 

\FAm  fa  " 

h  h 


and  Equation  (30)  to 

jE[Ss\Tr  =  t]fTr(t\h)dt=  J  E[Ss\Tr  =  t]1~V!('T}~^-dt 

(OJss]  (OJss-h]  ss 


For  H=h,  fTr(t  |  h)  has  the  form 
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au0(t)  fort  =  0 


1 


for  t  in  (0,4  - h ) 


Tss~h 

0  fort  in  [Tss-h,Tss] 


where  d(t)  in  Equation  (11)  is  actually  0  for  any  given  H=h.  Now  we  must  account  for  the 
fact  that  H  is  a  random  variable;  therefore,  we  must  determine  fTr(t): 

fTr (t)  =  Pr(7r  =  0)m0 (0  +  (1  - Pr(7r  =  0»  \fTr(t  \  h)f„ (h)dh 

(0  ,Tss] 


Letting  P=Pr(Tr=0)  and  Q=l-P,  we  have 

/„«)  =  Pu,(t)  +  ej  f»  (h)dh 

(0  ,Tss]Iss  n 

where  fH(h)  is  the  density  function  for  H.  To  determine  the  distribution  function  for  H,  we 
condition  on  whether  the  first  busy  period  in  the  renewal  interval  is  one  that  starts  within  the 
sporadic  server  (55)  or  is  a  hybrid  (hybrid).  Note  that 

fH  ( h )  =  f(h  1 55)  Pr(55)  +  f(h  \  hybrid )  Pr (hybrid) 
where  Pr(SS)=pi  and  Pr(hybrid)=l-pi. 

First,  we  will  focus  on  f(h  |55).In  this  case,  replenishment  has  occurred  in  the  idle  interval 
before  the  busy  period  starts.  The  busy  period  (and  hence  the  blackout  period,  H)  starts  when 
the  next  arrival  occurs.  H  can  take  on  only  a  finite  set  of  values.  When  the  duration  of  the 
busy  period  is  less  than  or  equal  to  Tss,  Tt(H  =  Sa  \  SS)  =  Pr (BP  —  1) , 
pr  (H  =  2  Sa  |  SS)  =  Pr  (BP  =  2) ,  and  so  forth.  However,  when  the  duration  of  the  busy  pe¬ 
riod  is  greater  than  Tss,  H  can  take  on  other  values— in  general,  those  in  the  following  set: 


A  mod  4  |  ;  =  1, 


LCM(Sa,TJ 


For  example,  if  Sa  =30  and  Tss=100,  H  can  be  equal  to  30, 60,  90,  20, 50,  80, 10, 40, 70,  and 
0.  The  probability  function  for  this  can  be  expressed  as 


18  Assuming 


is  rational. 
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Pr(H  =  jSamodTss  \  SS)  =  ?t(BP  =  i*L+j ) 
forL=  LCM =  and  i  >  0 

S, 


and  therefore 

f u  ( h  |  SS)  =  £u0(h  -  jSamodTss)£?r(BP  =  i*L+j)  19  1 

j=l  <=o 

Now,  we  will  focus  on  f(h  |  hybrid )  .  In  this  case,  replenishment  occurs  during  a  busy  period 
of  which  the  blackout  period  is  a  subinterval.  When  the  busy  period  is  less  than  Tss  in  dura¬ 
tion,  we  assume  that  replenishment  is  equally  likely  to  occur  at  any  time  during  that  busy  pe¬ 
riod.  Therefore,  the  time  from  replenishment  to  the  end  of  the  busy  period  is  uniformly  dis¬ 
tributed  over  the  length  of  the  busy  period,  that  is 

fH(h  |  Hybrid, BP  =  i,iSa<Tss)  =  ^-for  h& [0,15 J 

l$a 

=  0  otherwise 


When  the  length  of  the  busy  period  exceeds  Tss,  the  first  replenishment  must  be  within  Tss  of 
the  busy  period’s  beginning.  If  the  first  replenishment  is  exactly  at  the  beginning  of  the  busy 
period,  the  blackout  period  is  m  =  iSa  mod  Tss .  As  the  replenishment  moves  away  from  the 

beginning  of  the  busy  period,  h  decreases  until  it  is  0,  jumps  to  Tss,  and  then  decreases  until 
its  value  becomes  m  again  when  the  replenishment  occurs  at  Tss.  Therefore,  when  the  busy 
period  is  greater  than  or  equal  to  Tss,  the  probability  density  function  of  its  length,  H,  is  given 

by 

fif  (h |  Hybrid, iSa  >Tss)  =  ^-for  he  [0, Tss ] 

*ss 

=  0  otherwise 


Therefore 

eo 

fH  (h  |  Hybrid )  =  (fc)Pr(flP  =  i),  where 

im.  1 

G,  (h)  = - \ - for  h g  [0,min(iSa  ,TSS )] 

min(iSa,Tss) 

=  0  otherwise 


(35) 


19  Recall  that  Uo(x)  is  the  Dirac  delta  function.  Therefore,  Uo(x-a)  has  a  nonzero  (actually  infinite) 
value  when  x=a  and  is  zero  everywhere  else. 
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Note  that  we  have  made  the  assumption  that  the  distribution  governing  BP  does  not  depend 
on  whether  the  busy  period  starts  within  a  sporadic  server  or  starts  with  a  hybrid. 

Combining  Equations  (33),  (34),  and  (35),  we  have 

fH  (h)  =  Pr  (SS)£  u0  (h  -  jSamodTss  )£  Pr  (BP  =  i*L  +  j)  + 

H  -=°  (36) 

Pr(hybridj^jGi  (h)  Pr(BP  =  i) 

1=1 

Combining  Equations  (32)  and  (36),  we  have 
fTr(t)  =  Pu0(t)  +  Q  ?t(SS)^M j(t)^?r(BP  =  i*L+  j )  + 

j=l  «= o  (37) 

Q  Pr  {Hybrid)  f  ^  Gt  ( h )  Pr  (BP  =  i)dh 

(0Jss]Tss  ~k  «=1 


Integrating  Equation  (37),  we  have 


fTr(t)  =  Pu0(t)  +  (2  Pr(55)2M;(02Pr(5P  =  I‘*L+^  + 


i=0 


IfJ 


QPr(Hybrid)  £Pr (BP  = 


1=1 


QP, (Hybrid)  fiPr(BP  =  i)flnZ 

'if  j*‘ 


ss 

t J 


(38) 


where 


/,(*)  = 


-s-lnl 

iS„ 


\TSS  iSa  j 


iS„  {  t  . 


for  t<Tss  -iSa 
for  t>Tss-iSa 


and 
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M,(f)  = 


1 


— ,  fort  <TSS-  jSa  mod  T„ 
Tss-jSa  mod  r5I 

0,  far  t>Tss-  jSa  mod  7; 


Now  that  we  have  frr(t),  we  are  ready  to  evaluate  the  right-hand  side  of  Equation  (10): 
E[Ss]=  | E[Ss  | Tr  =  t]dFTr (t)  = 


[0  Jss] 

PE[Ss\Tr  =  0]  + 


Q  Pr(SS)£ 


M{Tss-jSa  modTss) 


w  Tj,  jSa  mod  Tss 

|]T  Pr (BP  =  i*L+  j)  jE[Ss\Tr  =  W  + 

1=0  0 


QPr(Hybrid)\ 


Pr(PP  =  0 


1=1 


1 


T 

T-lnl - *- 


iS„ 


\Ts,-iS, 


\Tss~iSaJ 


J  £[Ss  |  Tr  =  t]dt  ■ 


-i-  |  In (LsAE[Ss\Tr  =  t]dt 

iSa  T„-iS. 


|;Pr(BP  =  t)^-Jlnf^-W \Tr  =  t]dt 
,=[gj+i  T"  “  V  1  J 


L  ss  0 


Evaluating  E[Ss  |  Tr=t].  To  complete  our  analysis,  we  need  an  algorithm  to  compute 
E[Ss|  Tr=t].  Recall  that  we  offered  a  pessimistic  estimate  above.  A  more  general  form  of 
Equation  (24)  is  given  by 

£pr(BP  =  i)V;.(0 

fits,  |r.  =<)=  M  mep] - 

where  Vj(t)  is  the  total  duration  of  i  service  times,  starting  at  Tr=t.  Calculating  Vs(t)  requires 
calculating  how  many  hybrids  will  occur  during  the  busy  period  and  what  the  service  time  is 
for  each  of  those  hybrids. 

The  number  of  hybrids  in  the  busy  period  is  given  by 


*,(»  = 


iSn+Tss-t 

1 

(iS„  +  T„  -t)  mod  Tss 

Tss 

T 

TSs 

-1 
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A  hybrid  has  one  part  that  occurs  before  replenishment  and  one  that  occurs  after  it.  The  dura¬ 
tion  of  the  part  that  occurs  before  replenishment  for  the  j01  hybrid  is 


dj(t)  =  {t  +  (j-l)Tss)- 


t+U-Ws 


The  total  duration  of  the  hybrid  is 

dj  (t)  +  Sa-  dj  (0(1  -Up)  =  S0+dj(t)Up=Saa-Up)+ dj  (t  )Up 


The  duration  of  the  busy  period  is 


V,(f) 


(i  -  k,  (r))S„  +  ‘f ’  -  vt ) + i,  w,  )=  (>'  -  *,  (t)Ur  K+Ldj  (r)f/,  for  t  >  0 

7=1  >=' 

k,(Tu) 

S^d-l-KiTJU^S^  2dj(Tss)Up  for  t  =  0 


4.4.3  Areas  of  Ongoing  Work 

In  Section  4.4.1,  we  made  several  simplifying  assumptions  that  we  are  in  the  process  of  re¬ 
laxing: 

•  In  computing  Pr(Tr=0),  we  assumed  there  would  be  many  busy-idle  cycles  over  the 
course  of  a  replenishment  period.  In  other  words,  we  assumed  that  (E[B]+E[I])/TSS  <  1. 
When  Tss  is  small  or  the  traffic  intensity  is  high  enough  to  cause  E[B]  to  exceed  Tss,  this 
assumption  is  violated.  Such  a  violation  can  cause  inaccuracy  in  our  prediction  of 
Pr(Tr=0)  and,  in  turn,  an  inaccurate  weighted  average  of  E[Ss|  Tr=0]  and  E[Ss|  Tr>0]. 

•  When  computing  the  blackout  time  for  the  hybrid  case,  we  assumed  that  the  first  replen¬ 
ishment  of  a  busy  period  is  equally  likely  to  occur  anywhere  in  [0,  min(£Sfl  ,TSS )  ].  How¬ 
ever,  the  length  of  the  blackout  period  might  be  constrained  after  a  busy  period  occurs. 
For  example,  when  one  busy  period  ends  very  close  to  replenishment  and  the  next  one 
starts  shortly  thereafter,  there  is  a  constraint  on  how  short  the  blackout  period  can  be. 
Figure  15  shows  an  example  of  that  situation.  The  busy  period  BPi  was  hit  by  a  replen¬ 
ishment  at  time  460,  creating  a  blackout  hi=40  for  when  the  following  busy  period  could 
start.  We  can  see  that  the  blackout  h2  created  by  BP2  is  30,  but  even  if  BP2  started  right 
after  BPi  finished  at  time  500,  the  blackout  h2  could  be  no  less  than  20. 

•  In  computing  E[Ss|  Tr=0]  and  E[Ss|  Tr=t] ,  when  t>0  we  condition  on  the  number  of  arri¬ 
vals  in  the  busy  period  and  then  uncondition  using  the  M/D/1  busy  period  distribution 
(see  Equation  (22)).  However,  due  to  an  effect  known  in  renewal  theory  as  length  biasing 
[Ross  96],  there  is  a  bias  toward  replenishments  occurring  in  relatively  long  busy  periods. 
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In  other  words,  the  distribution  of  the  lengths  of  hybrid  busy  periods  is  different  from  the 
distribution  of  all  the  busy  periods;  the  probability  is  shifted  toward  longer  busy  periods. 


400  500  600 

Figure  15:  Tr  Blackout  Dependency  on  Previous  Blackout 

We  are  currently  looking  into  generalizing  the  theory  to  account  for  the  cases  in  which  our 
assumptions  are  not  appropriate. 

4.4.4  Empirical  Evidence 

In  this  section,  we  offer  two  examples  of  using  the  theory  developed  in  the  previous  section. 
Figure  16  shows  a  histogram  showing  the  predicted  and  simulated  probability  density  for 
time  to  replenishment. 

The  spike  shown  at  the  beginning  of  Figure  16  for  the  prediction  curve  represents  Pr(Tr=0), 
and  the  remainder  of  the  curve  is  frr(t). 
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o  20  40  60  80  100 

Tr 

Figure  16:  fTr(t)  Predicted  Versus  that  Observed  Through  Simulation 

The  next  three  figures  (using  the  same  parameters  as  Figure  8  where  Tp  is  set  to  1)  show  pre¬ 
dictions  versus  simulations  for  the  average  latency  (E[W]),  average  queuing  time  (E[Q]),  and 
average  service  time  (E[Ss])  respectively.  The  predictions  for  the  average  queuing  time  ap¬ 
pear  to  be  fairly  accurate.  The  predictions  for  average  service  time  appear  to  be  accurate  until 
Up  exceeds  0.65.  As  discussed  in  Section  4.4.3,  as  the  average  duration  of  the  busy  period 
increases  (which  happens  as  Up  increases)  and  starts  to  approach  Tss,  our  approach  for  calcu¬ 
lating  Pr(Tr=0)  becomes  less  accurate,  which,  in  turn,  affects  the  accuracy  of  E[Ss]. 
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re  17:  E[W]  Predicted  Versus  that  Observed  Through  Simulation 
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Figure  18:  E[Q]  Predicted  Versus  that  Observed  Through  Simulation 
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Figure  19:  E[Ss]  Predicted  Versus  that  Observed  Through  Simulation 

4.5  Single-Subtask  Assemblies 

In  this  section,  we  look  at  assemblies  with  three  periodic  tasks  and  an  aperiodic  task  managed 
by  a  sporadic  server.  Anticipating  applying  our  theory  to  more  general  assemblies,  we  make 
some  observations  about  multitask  assemblies. 

Varying  utilization  equally.  For  this  case,  there  is  an  aperiodic  task  and  multiple  periodic 
tasks  between  which  the  periodic  utilization  is  evenly  divided.  The  average  latency  for  the 
multi-periodic  case  should  fall  within  the  extremes  of  the  single  periodic  cases.  The  parame¬ 
ters  for  this  graph  are  Ta=200,  Sa=Sss=10,  and  Tss=100,  while  Tp  and  Up  vary  accordingly. 

This  case  is  shown  in  Figure  20  except  for  when  Up  is  large:  we  intend  to  investigate  this  fur¬ 
ther. 
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Utilization  Spread  Equally  Between  Several  Periodics 


—  Tp  =  (100, 250, 350) 
Tp=1 00 

Tp=350 _ 


0  0.1  0.2  0.3  0.4  0.5  0.6  0.7  0.8  0.9  1 
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Figure  20:  Multi-Periodic  Example— Utilization  Evenly  Divided 

Varying  utilization  unequally.  In  the  previous  case,  there  was  a  single  aperiodic  task  and 
three  periodic  tasks.  However,  in  this  case,  the  total  utilization  of  the  periodics  (which  varies 
from  0  to  .9)  is  spread  unevenly  among  the  three  periodic  tasks.  In  the  legend  of  Figure  21, 
“.8  .1 .1”  means  that  for  a  utilization  level  of  Up,  .8*  Up  is  accorded  to  the  task  whose  period 
is  100,  .1*  Up  is  accorded  to  the  task  whose  period  is  250,  and  .1*UP  is  accorded  to  the  task 
whose  period  is  350.  Additionally,  we  plot  the  single  periodic  case  for  Tp=100  and  Tp=350. 
Again,  except  for  relatively  large  values  of  Up,  the  single  periodic  cases  create  an  envelope 
around  the  multi-periodic  cases. 
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Utilization  Spread  Unevenly  Between  Several 
Periodics 
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Figure  21:  Multi-Periodic  Example— Utilization  Unevenly  Divided 
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4.6  Multi-Subtask  Assemblies 

We  took  the  multi-periodic  case  shown  in  Figure  20  and  turned  each  periodic  task  into  one 
that  had  multiple  subtasks  with  arbitrary  priorities.  The  graph  in  Figure  22  shows  the  results. 


Figure  22:  Multi-Periodic  Example  with  Multiple  Subtasks 
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Notice  that  the  graphs  in  Figure  22  and  Figure  20  are  identical.  As  long  as  the  system  is  work 
conserving  (i.e.,  it  continues  to  do  available  work  without  idling),  the  periodics’  priority  and 
subtask  structures  do  not  influence  the  average  latency  of  the  aperiodics.  This  lack  of  influ¬ 
ence  occurs  because  the  periodic  subassembly’s  priority  and  subtask  structure  do  not  influ¬ 
ence  when  background  is  available. 


This  allows  an  arbitrarily  complex  periodic  task  to  be  simplified  to  an  equivalent  periodic 
single-subtask  task. 


4.7  Observations  on  the  No-Background  Case 

Notice  that  in  Figure  8,  Figure  21,  and  Figure  22,  the  length  of  the  periodic  task’s  period  in¬ 
fluences  when  the  aperiodic  task’s  average  latency  reaches  the  point  of  so-called  “no  back¬ 
ground.”  To  understand  this  situation,  consider  the  two  extreme  cases:  infinitesimal  periods 
(continuous  background)  and  very  large  periods. 

In  the  continuous  background  case,  Sq  approaches  T*  as  Up  increases.  When  Up=l-Sss/Tss, 

Sq  (which  is  equal  to  Sa  )  is  equal  to  Tss.  This  is  the  maximum  possible  value  for  Sq  (as  guar¬ 
anteed  by  the  sporadic  server).  Therefore,  the  continuous  background  case  reaches  a  state  of 
“no  background”  when  Up=l-Sss/Tss.  Notice  that  while  the  aperiodic  events  cannot  execute  in 
background,  the  processor  is  not  necessarily  fully  utilized.  For  example,  if  Sss=10,  Tss=100, 
Sa=10,  Ta=200,  and  Up=.9,  then  Sq=Tss=100  and  p=Sq/Ta=100/200=0.5.  This  means  that,  on 
average,  only  half  of  the  “degraded  processor”  is  actually  being  utilized.  In  other  words,  only 
half  of  the  unused  periodic  utilization  is  used  by  the  aperiodic  task. 

As  the  length  of  the  periodic  tasks’  period  increases,  the  aperiodic  task  is  able  to  use  this  un¬ 
used  capacity.  When  the  period  of  the  periodic  tasks  is  very  large,  the  aperiodic  task  can  exe¬ 
cute  both  within  the  sporadic  server  and  in  the  large  windows  of  periodic  idleness. 
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5  Application  of  the  Theory 


In  this  section,  we  describe  a  collection  of  heuristics  that  encompass  much  of  the  observa¬ 
tions  and  analysis  performed  in  Section  4.  We  then  describe  a  model  problem  from  the  do¬ 
main  of  robotics  and  show  how  to  apply  these  heuristics  derived  from  the  property  theory  to 
the  robotics  model  problem. 


5.1  Reasoning  Heuristics 

Much  of  this  report  has  focused  on  providing  a  theoretical  foundation  for  the  continuous 
background  case  with  a  single  periodic  task.  However,  important  conclusions  can  also  be  de¬ 
rived  from  empirical  evidence.  Sections  4.5  and  4.6  showed  that  with  some  targeted  simula¬ 
tions  we  can  get  a  good  understanding  of  aperiodic  latency  for  a  very  general  periodic  task 
set.  Based  on  our  theoretical  and  empirical  understanding,  we  generated  the  following  list  of 
heuristics: 

•  HI:  For  a  given  aperiodic  service  time  (Sa)  and  interarrival  interval  (Ta),  the  best-case 
average  latency  occurs  when  there  are  no  periodics  (Up=0).  The  latency  for  this  case  is 
predictable  by  Equation  (4). 

•  H2:  For  a  given  aperiodic  service  time  and  interarrival  interval,  the  worst-case  average 
latency  occurs  when  the  periodic  utilization  is  large  enough  so  that  aperiodics  execute 
only  within  the  sporadic  server  (no-background  case).  The  latency  for  this  case  is  pre¬ 
dictable  by  Equation  (6),  where  Sq=Tss. 

•  H3:  For  the  continuous  background  case,  given  Up,  E[Q]  can  be  predicted  accurately  by 
using  Equation  (9)  and  letting  Sq=Sa.  E[SJ  can  be  approximated  by  realizing  that  it  is 

a  weighted  average  of  Sa  and  Sa  and  therefore  is  between  those  two  extremes.  As  Up  gets 
larger,  Sa  starts  to  approach  Tss,  so  there  is  very  little  room  for  background  processing. 

In  this  case  (even  though  E[Q]  increases),  E[Ss]  approaches  Sa.  H3  applies  to  cases  in 
which  Up  is  greater  than  0  and  less  than  1-Sss/Tss. 

•  H4:  For  very  large  periodic  periods,  average  latency  as  a  function  of  Up  appears  to  be 
approximately  the  convex  combination  of  the  no-periodics  (NP)  and  no-background  (NB) 
cases.  H4  applies  to  cases  in  which  Up  is  greater  than  0  and  less  than  1-p.  Therefore,  in 
this  case 
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E[W] 
E[WNP]= 
E[Wnb]  = 


E[Wnb]-E\Wnp] 


1  -p 
N  E[Sl ] 
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1  -P) 

HI  ^ 
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+  £[SJ,ami 


+  E[Sal where p=^and Sa  <TaandSs  =TSS 


2  E[Sa] 


The  observations  gleaned  from  the  curves  generated  for  average-case  latency  for  aperiodic 
events  served  by  a  sporadic  server  (see  Figure  8)  provided  significant  understanding  of  the 
timing-related  behavior  of  such  events.  Figure  23  below  represents  an  abstraction  of  Figure  8 
with  the  heuristics  overlaid  to  illustrate  how  these  heuristics  support  predicting  aperiodic  la¬ 
tency. 


Figure  23:  Heuristics  Applied  to  the  Curves 

Notice  in  Figure  23,  HI  (the  best-case  average  latency)  and  H2  (the  worst-case  average  la¬ 
tency)  serve  to  bound  the  aperiodic  average  latency,  E[W].  Also  notice  that  for  a  specific 
value  of  Up,  H3  and  H4  seem  to  provide  bounds  for  E[W].  E[W],  then,  will  fall  between  the 
best-case  and  worst-case  average  latency  dictated  by  HI  and  H2,  within  the  region  further 
defined  by  H3  and  H4  for  a  specific  Up. 


In  the  next  section,  we  apply  these  heuristics  to  a  model  problem. 
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5.2  A  Robotics-Based  Model  Problem 

To  demonstrate  the  analytical  and  empirical  foundations  established  in  this  paper,  we  apply 
them  to  a  model  problem  [Hissam  04]  representative  of  a  design  problem  posed  for  the  ABB 
industrial  robotics  product  line. 

The  model  problem  expresses  the  high-level  task  structure  used  to  convey  robot  movement 
commands  through  a  series  of  queues  to  ultimately  control  the  various  axes  of  a  robot’s 
arm(s).  The  model  problem  permits  the  incorporation  of  additional  end-user  tasks  (or  exten¬ 
sions)  in  the  controller  similar  to  the  addition  of  a  third-party  device  driver  in  an  OS.  It  is  this 
extensibility  that  motivates  the  use  of  this  performance  theory.  That  is,  an  extension  will  be 
either  periodic  or  aperiodic  by  nature.  The  reasoning  framework  discussed  by  Hissam  and 
colleagues  [Hissam  02]  can  be  applied  to  predict  the  average  latency  of  periodic  extensions 
(see  Section  2.2).  The  analytical  and  empirical  foundations  introduced  in  this  report  can  be 
applied  to  predict  the  timing  behavior  of  aperiodic  extensions. 

In  summary,  the  robotics-based  model  problem  has 

•  periodic  and  aperiodic  tasks 

•  tasks  with  hard  deadlines  and  average-case  latency  requirements 

•  tasks  (for  example,  controller  extensions)  whose  behavior  must  be  both  predictable  and 
predictably  invasive  on  other  periodic  tasks  with  hard  deadlines 

•  requirements  for  predicting  deadline  miss  rates 

In  the  remainder  of  this  section,  we  apply  the  performance  theory  in  this  paper  to  predict  the 
average-case  latency  of  an  aperiodic  task  within  the  robotics-based  model  problem. 


5.2.1  Tasks  in  the  Model  Problem 

Figure  24  provides  a  schematic  of  the  open  robotics  model  problem.  In  this  discussion,  we 
simplify  the  model  further  by  concentrating  on  only  one  task  set — A-B-C  (controlling  a  robot 
with  only  one  arm) — and  one  “plug-in”— task  M. 
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Figure  24:  Tasks  in  the  Robotics  Model  Problem 

Tasks  A,  B,  and  C  each  convey  commands  through  a  series  of  queues.  Task  M  represents  a 
third-party  task  extension  to  the  robotics  controller. 

Table  2  shows  the  applicable  task  performance  specifications  of  the  tasks  in  Figure  24. 


Table  2: 


Performance  Description  of  Model  Problem  Tasks 


Task 

Priority 

Arrivals 

Execution  Time 

Aj 

Low 

Exponentially  distributed 
with  mean 

75  ms 

Exponentially  dis¬ 
tributed  with  mean 

9  ms 

Bi 

High 

Constant 

24ms 

Uniform 

1-2  ms 

C 

Very 

High 

Constant  4ms 

Uniform 

0.5-1  ms 

M 

Med 

Exponentially  distributed 
with  mean 

100  ms 

Uniform 

15-25  ms 

5.2.2  Analysis  Setup 

We  are  interested  in  two  questions  in  particular: 

1.  Will  including  Task  M  cause  Tasks  A,  B,  and  C  to  miss  their  deadlines? 

2.  What  is  the  average-case  latency  of  events  handled  by  Task  M? 


To  answer  these  questions,  we  take  a  closer  look  at  Tasks  A,  B,  and  C. 
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Task  A  is  a  low-priority  task  that  is  handling  a  stream  of  aperiodic  arrivals.  Each  aperiodic 
arrival  is  broken  down  into  a  sequence  of  subitems  and  placed  on  the  queue  between  Task  A 
and  B. 

Task  B  continues  to  periodically  process  a  subitem  from  the  Task  A-B  queue,  further  decom¬ 
poses  that  subitem,  and  places  the  resulting  decompositions  on  the  queue  between  Tasks  B 
and  C. 

The  period  of  Task  B  (i.e.,  24  ms)  is  6  times  the  period  of  Task  C  (i.e.,  4  ms).  That  is  true  be¬ 
cause  for  every  subitem  processed  by  Task  B  (generating  6  microcoordinates).  Task  C  will 
consume  a  microcoordinate  from  the  Task  B-C  queue  and  send  it  to  the  Axis  computer 
(which  itself  takes  about  1  ms).  Task  C  then  can  consume  all  six  microcoordinates  on  the 
Task  B-C  queue  within  the  period  of  Task  B. 


Ideally,  Task  A  should  never  allow  the  queue  between  Task  A  and  B  (i.e.,  the  Task  A-B 
queue)  to  empty.  Unfortunately,  Task  A  is  only  given  low  priority  in  the  controller  because, 
under  certain  conditions,  Task  A  may  take  an  inordinate  amount  of  CPU  time  to  perform  its 
item  decomposition.  If  Task  A  were  assigned  a  higher  priority  relative  to  Task  B  or  Task  C, 
Task  A  could  cause  either  of  those  tasks  to  miss  its  deadline.  At  low  priority,  Task  A  is  as¬ 
sured  not  to  interfere  with  the  deadlines  of  Tasks  B  and  C.  However,  with  the  inclusion  of  an 
extension  to  the  controller.  Task  A  could  be  starved  to  the  point  that  it  could  inadvertently 
starve  the  Task  A-B  queue. 

To  solve  this  conundrum  and  ensure  that  Task  A  does  have  the  opportunity  to  put  at  least  one 
subitem  on  the  Task  A-B  queue  within  the  period  of  Task  B,  Task  A  can  be  converted  to  use 
the  SSSA.20  In  this  case,  Task  A  can  be  given  just  enough  execution  time  to  prevent  the  Task 
A-B  queue  from  being  emptied.  Further,  given  that  Task  A  is  following  the  SSSA,  Task  A  can 
now  be  treated  like  a  periodic  task. 

Understanding  the  interactions  between  Tasks  A,  B,  and  C  and  treating  Task  A  as  a  periodic 
task  allow  us  to  apply  the  results  of  Section  4.5  that  deal  with  single-subtask  assemblies.  This 
analysis  asserts  that  assemblies  with  multiple  periodic  tasks  can  be  analyzed  by  considering 
single-task  assemblies  whose  utilization  (Up)  is  the  same  as  that  of  more  complex  assemblies 
and  by  varying  the  periods  between  the  smallest  and  largest  periodic  periods. 


20  This  point  is  another  design  issue  that  Hissam  and  Klein  address  in  another  report  [Hissam  04]. 
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This  means  that  the  task  set  (A-B-C)  in  Figure  24  can  be  combined  into  a  single  periodic  task 
for  which  Tp  =  24  ms  (Task  B’s  period)  and  the  execution  time  is  approximately  10  ms.21 
Figure  25  shows  the  final  periodic  single  subtask  created  to  support  the  analysis  of  the  robot¬ 
ics  model  problem. 


Main  Computer 


Figure  25:  Analytic  Representation  of  the  Robotics  Model  Problem 

The  performance  parameters  for  the  extension  (i.e..  Task  M)  can  be  taken  mostly  from  Table 
2.  Task  M  is  an  aperiodic  task  managed  by  the  SSSA.  Its  interarrival  interval  (Ta)  is  100  ms. 
The  replenishment  period  for  Task  M  is  not  specified;  however,  Tss  must  be  >  Tp,  otherwise 
the  aperiodic  task  might  be  able  to  preempt  the  periodic  task  more  than  once  during  its  period 
and  put  the  periodic’s  deadline  at  risk.  Tss,  then,  can  (at  best)  take  on  the  value  of  24  ms. 


The  last  two  performance  parameters  for  Task  M  are  Sss  (budget)  and  Sa  (execution  time), 
The  upper  limit  for  Sss  (given  that  Tss=24  ms)  is  determined  by  the  total  utilization  of  the  two 
tasks  in  Figure  25.  The  highest  value  for  S*  must  be  14  ms,  resulting  in  a  total  utilization  for 
Task  M  being  14/24  (Sss/Tss).  Finally  for  Sa,  Section  4  states  in  the  governing  assumptions 
that  Sa=Sss;  we  will  assume  that  Task  M’s  execution  time  is  a  constant  14  ms  and  perform  our 
analysis  from  this  point. 


5.3  Preserving  Periodic  Deadlines 

The  first  question  is  whether  Task  M  will  cause  the  A-B-C  task  set  to  miss  its  deadline.  This 
set  executes  for  10  ms  every  24  ms  with  a  deadline  at  the  end  of  its  period.  In  the  worst  case, 


2*  Assuming  the  worst  case,  execution  times  for  Tasks  B  and  C  are  2  ms  and  6  ms,  respectively 
(from  Table  2— recall  that  Task  C  will  execute  for  1  ms,  6  times  during  Task  B’s  24-ms  period); 
Task  A’s  execution  time  is  based  on  the  time  it  takes  to  produce  1  subitem  from  its  input  stream: 
approximately  1-2  ms.  The  sum  of  these  approximate  times  is  just  under  10  ms. 


50 


CMU/SEI-2004-TR-01 7 


Task  M  will  preempt  the  A-B-C  task  set  once  for  14  ms,  implying  a  worst-case  latency  of  24 
ms  for  the  task  set  and,  hence,  guaranteeing  the  set’s  deadline. 


5.4  Predicting  Average-Case  Latency 

The  second  question  is  to  predict  the  average-case  latency  of  the  aperiodic  extension  (Task 
M).  In  this  section,  we  apply  heuristics  from  Section  5.1. 


Heuristic  HI — best-case  average  latency:  Sa  =  14;  Ta  =  100;  p  =  Sa  /  Ta  -  14/100  -  0.14. 
Solving  for  Equation  (4),  we  get  the  following: 


E[W]  = 


1  -P. 


ms.] 


+  E[Sa] 


\14 

..86. 


v2*14 
=  15.13953 


2  >\ 

+  14 


14z 


(39) 


Heuristic  H2 — worst-case  average  latency:  E[Sq]  —  Tss;  E[Ss]  —  Sa;  pq  —  Sq  /  Ta  —  24/100 
0.24.  Solving  for  Equation  (6),  we  get  the  following: 


(40) 


Heuristic  H3— bound  on  average-case  latency  for  continuous  background  for  a  specific  Up: 
Since  Up=l  -  (Sss  /  Tss)  in  this  model  problem,  H3  cannot  be  used. 


Heuristic  H4 — bound  on  average-case  latency  for  large  Tp  for  a  specific  Up:  p  =  Sa  /  Ta  = 
14/100  =  0.14.  Using  the  equation  from  H4,  we  get  the  following: 


CMU/SEI-2004-TR-01 7 


51 


E[W]  = 


1  -P 


VP  + 


E[WNP],  where 


E\Wnp]  = 


E\Wnb]  = 


£[S2] 

2E[SJ 

'  g[S23 

2E[Sa] 


+  E[Sa],and 

A 

s 

+  E[Sa], where p  =  ~rand Sa  < Ta and Ss  =  Tss 

*  n 


For  E[Wnp],  we  can  use  the  result  calculated  for  HI  above:  E[Wnp]  =  15.13953.  For  E[WNB], 
we  can  use  the  result  calculated  from  H2  above:  E[Wnb]  =  17.78947.  Then,  solving  for  E[W], 
we  get  the  following: 


E\W)  = 


£[Wvh]-£[Wwp] 
1  ~P 


UD+E[WNP] 


( 17.78947 -15.13953  Vq/24n  +  15  13953 


v  .86 
=  16.42342 


Heuristic  HI  tells  us  that  for  the  model  problem,  we  can  expect  the  average  latency  to  be  no 
better  than  15. 13953  ms.  Further,  H2  tells  us  that  we  can  expect  the  average  latency  to  be  no 
worse  than  17.78947  ms.  We  can  refine  the  lower  bound  for  Up  =  10/24  =  0.4166  (see  Figure 
26)  by  applying  H4;  the  result  is  16.42342  ms. 


By  overlaying  the  results  from  the  heuristics  just  computed  to  a  plot  of  curves  representing 
latencies  observed  through  simulation,  it  is  possible  to  check  the  heuristics.  Figure  26  was 
created  through  simulation.  All  the  performance  parameters  from  Figure  25  were  used  in  the 
simulation  except  for  Tp  and  Up,  which  varied.  The  simulation  was  run  for  13  values  of  Up 
(specifically  0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.75, 0.8, 0.85, 0.9,  and  0.95)  for  each  Tp 
shown  in  the  legend  of  the  figure.  The  average  latency  for  the  aperiodic  Task  M  was  com¬ 
puted,  recorded,  and  plotted  based  on  the  specific  Up  and  Tp  for  that  simulation. 
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Figure  26:  Latency  Observed  for  the  Model  Problem  for  Various  Tp  Values 


As  described  in  Section  4.7,  the  no-background  state  is  reached  at  different  periodic  utiliza¬ 
tions  for  different  periodic  periods.  For  this  model  problem,  the  no-background  state  is 
reached  at  a  much  smaller  utilization  for  very  small  periods  than  for  very  large  ones.  The  net 
effect  is  that  the  above  graph  almost  looks  like  an  inverted  version  of  Figure  8. 


Table  3  shows  the  side-by-side  comparisons  of  the  heuristics  calculated  and  the  averages  ob¬ 
served  through  simulation  in  Figure  26. 


Table  3:  Comparison  of  Prediction  Heuristics  and  Simulation  Curves 


Computed  Heuristic 
(in  ms) 

Observed  in  Simulation 
(in  ms) 

HI:  Best-Case  Average  Latency 

15.13953 

15.10088 

H2:  Worst-Case  Average  Latency 

17.78947 

17.78476 

H4:  Bound  for  Large  Tp 

16.42342 

16.35977 

Because  the  model  problem  represents  an  extreme  case  where  Up  =  1  -  Sss  /  Tss  (i.e.,  the  no¬ 
background  case),  the  heuristic  H2  should  offer  an  accurate  prediction.  The  value  computed 
for  H2  was  compared  to  the  average  latency  observed  in  many  simulations  of  the  model  prob¬ 
lem.  These  results  are  reported  in  Table  4.  The  prediction  of  17.78947  ms  was  found  to  be 
within  2  standard  errors  of  the  observed  latency  of  17.79473  ms. 
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Table  4:  Predicted  and  Actual  Average-Case  Latency  for  Task  M 


Basic  Statistics 

Value 

Samples  (n) 

1035 

Average  Aperiodic  Latency  Observed 

17.79473  ms 

Standard  Deviation  (a) 

0.12574  ms 

Predicted  Aperiodic  Latency  (E[W]) 

17.78947  ms 

Error 

0.00526 

Standard  Error 

0.00391 

2  x  Standard  Errors 

0.00782 
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6  Conclusions 


This  report  documents  the  development  and  application  of  a  theory  for  predicting  the  average 
latency  of  aperiodic  tasks  that  execute  under  the  management  of  a  sporadic  server.  The  notion 
of  a  sporadic  server  was  invented  many  years  ago,  but  this  is  the  first  time  a  detailed  queue¬ 
ing-theoretic  analysis  has  been  performed.  Such  analysis  represents  a  step  in  the  direction  of 
creating  a  comprehensive  set  of  performance  reasoning  frameworks  that  includes  using  RMA 
for  a  deterministic  deadline  analysis,  queueing  theory  for  average  latency  analysis,  and  a  new 
theory  known  as  real-time  queueing  theory  (RTQT)  [Doytchinov  01]  for  probabilistic  analy¬ 
sis  of  deadline  miss  rates. 

This  report  focused  on  task  sets  with  the  following  characteristics: 

•  The  assemblies  are  confined  to  a  single  processor. 

•  Each  periodic  event,  whether  clock  or  message  based,  is  handled  by  one  task  (or  a  se¬ 
quence  of  tasks).  Each  periodic  task  has  an  associated  period  and  an  execution  time  (or 
sequence  of  execution  times). 

•  All  aperiodic  events  are  funneled  through  a  sporadic  server. 

•  The  sporadic  server  runs  at  the  highest  priority  in  the  system  and  is  characterized  by  an 
execution  budget  and  a  replenishment  period. 

•  The  service  time  for  each  aperiodic  event  is  constant  and  equal  to  the  execution  budget  of 
the  sporadic  server. 

•  The  aperiodic  arrivals  arrive  according  to  an  exponential  distribution  with  a  specified 
mean  interarrival  interval.  We  only  consider  a  single  stream  of  aperiodic  events. 

•  Aperiodic  events  are  allowed  to  use  the  CPU  when  either  the  sporadic  server  has  suffi¬ 
cient  budget  or  the  periodics  are  idle. 

The  analytical  and  empirical  results  described  in  this  paper  are  applicable  to  a  very  large 
spectrum  of  assemblies.  In  fact,  the  periodic  assemblies  can  be  arbitrarily  complex. 


6.1  Future  Work 

While  we  have  gained  many  insights  from  examining  a  specific  class  of  assemblies,  our  ob¬ 
jectives  are  to  solidify  the  theoretical  foundations  for  what  we  have  discussed  in  this  paper 
and  to  relax  the  assumptions,  investigating  a  more  general  set  of  assemblies. 
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•  We  would  like  to  gain  a  better  understanding  of  the  “middle  period  cases.”  We  under¬ 
stand  much  about  the  cases  where  the  period  of  the  periodics  is  very  small  (relative  to  Sss) 
and  very  large.  However,  we  have  only  just  begun  to  understand  the  midrange  periods. 

•  We  need  to  experiment  with  multi-periodic  assemblies  with  a  larger  number  of  tasks.  We 
suspect  that  we  can  create  situations  in  which  the  average  latency  of  the  aperiodics  is 
even  better  than  the  lower  bound  we  observed  in  multi-periodic  cases  discussed  in  this 
report. 

•  We  have  enumerated  several  places  where  our  mathematical  modeling  needs  to  be  im¬ 
proved  including  accounting  for  length  biasing,  refining  our  blackout  distributions,  and 
accounting  for  when  many  replenishments  occur  during  a  busy  period. 

•  We  intend  to  combine  RTQT  with  the  sporadic  server  for  predicting  the  probability  of 
missing  deadlines. 

•  Currently,  arrivals  and  service  time  distributions  are  constrained  to  exponential  and  con¬ 
stant  distributions,  respectively.  Heavy  traffic  approximations  might  allow  us  to  acquire 
an  analytic  understanding  while  relaxing  these  restrictions.  In  any  case,  we  will  perform 
empirical  studies. 

•  Currently  the  sporadic  server  is  confined  to  Sss  =  Sa,  Sa  is  confined  to  being  constant,  and 
the  sporadic  server  must  execute  at  the  highest  priority.  We  will  investigate  relaxing  these 
restrictions  and  whether,  with  a  more  general  sporadic  server  capability,  we  may  have 
more  control  over  the  average  latency  of  the  aperiodics. 

•  So  far,  we  have  only  investigated  the  uniprocessor  case.  In  the  future,  we  plan  to  investi¬ 
gate  the  distributed  problem. 

•  Earlier,  we  briefly  investigated  applying  RTQT  in  a  fixed-priority  setting.  We  will  con¬ 
tinue  that  investigation. 

•  We  plan  to  implement  an  earliest  deadline  first  (EDF)  capability  in  our  runtime  infra¬ 
structure — a  natural  setting  for  applying  RTQT. 

We  plan  to  pursue  the  above  areas  with  an  eye  towards  their  practical  application. 
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